April 2022 - Linux-stable-mirror

by Mark

Hello, The HSBC Bank is a financial institution in United Kingdom. We promotes long-term,sustainable and broad-based economic growth in developing and emerging countries by providing financial support like loans and investment to large, small and medium-sized companies (SMEs) as well as fast-growing enterprises which in turn helps to create secure and permanent jobs and reduce poverty. If you need fund to promotes your business, project(Project Funding), Loan, planning, budgeting and expansion of your business(s) , do not hesitate to indicate your interest as we are here to serve you better by granting your request. Thank you Mr:Mark

3 years, 8 months

1
0
0 0

Hello,

by Seyba Daniel

Hello, I am so sorry contacting you in this means especially when we have never met before. I urgently seek your service to represent me in investing in your region / country and you will be rewarded for your service without affecting your present job with very little time invested in it. My interest is in buying real estate, private schools or companies with potentials for rapid growth in long terms. So please confirm interest by responding back. My dearest regards Seyba Daniel

3 years, 8 months

1
0
0 0

Greetings,

by Mr. Jibri loubda

-- Greetings, I'm Mr. Jibri loubda, how are you doing hope you are in good health, the Board irector try to reach you on phone several times Meanwhile, your number was not connecting. before he ask me to send you an email to hear from you if you are fine. hope to hear you are in good Health. Thanks, Mr. Jibri loubda. Sincerely, Dr. Irene Lam.

3 years, 8 months

1
0
0 0

[PATCH AUTOSEL 4.9 1/7] drm/amdkfd: Check for potential null return of kmalloc_array()

by Sasha Levin

From: QintaoShen <unSimple1993(a)163.com> [ Upstream commit ebbb7bb9e80305820dc2328a371c1b35679f2667 ] As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. Signed-off-by: QintaoShen <unSimple1993(a)163.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c b/drivers/gpu/drm/amd/amdkfd/kfd_events.c index 6a3470f84998..732713ff3190 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c @@ -607,6 +607,8 @@ static struct kfd_event_waiter *alloc_event_waiters(uint32_t num_events) event_waiters = kmalloc_array(num_events, sizeof(struct kfd_event_waiter), GFP_KERNEL); + if (!event_waiters) + return NULL; for (i = 0; (event_waiters) && (i < num_events) ; i++) { INIT_LIST_HEAD(&event_waiters[i].waiters); -- 2.35.1

3 years, 8 months

2
7
0 0

[PATCH v3] iio: imu: inv_icm42600: Fix I2C init possible nack

by Jean-Baptiste Maneyrol

From: Fawzi Khaber <fawzi.khaber(a)tdk.com> This register write to REG_INTF_CONFIG6 enables a spike filter that is impacting the line and can prevent the I2C ACK to be seen by the controller. So we don't test the return value. Fixes: 7297ef1e261672b8 ("iio: imu: inv_icm42600: add I2C driver") Signed-off-by: Fawzi Khaber <fawzi.khaber(a)tdk.com> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> --- drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c index 33d9afb1ba91..01fd883c8459 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c @@ -18,12 +18,15 @@ static int inv_icm42600_i2c_bus_setup(struct inv_icm42600_state *st) unsigned int mask, val; int ret; - /* setup interface registers */ - ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG6, + /* + * setup interface registers + * This register write to REG_INTF_CONFIG6 enables a spike filter that + * is impacting the line and can prevent the I2C ACK to be seen by the + * controller. So we don't test the return value. + */ + regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG6, INV_ICM42600_INTF_CONFIG6_MASK, INV_ICM42600_INTF_CONFIG6_I3C_EN); - if (ret) - return ret; ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG4, INV_ICM42600_INTF_CONFIG4_I3C_BUS_ONLY, 0); -- 2.17.1

3 years, 8 months

2
1
0 0

opportunity

by Allen S

Hello, I lead family investment vehicles who want to invest a proportion of their funds with a trust party . Please if you are interested in discussing investment in your sector? Please email, or simply write to me here. I value promptness and will make every attempt to respond within a short time. Thank you. Allen S.

3 years, 8 months

1
0
0 0

[PATCH] Documentation: dd: Use ReST lists for return values of driver_deferred_probe_check_state()

by Bagas Sanjaya

Sphinx reported build warnings mentioning drivers/base/dd.c: </path/to/linux>/Documentation/driver-api/infrastructure:35: ./drivers/base/dd.c:280: WARNING: Unexpected indentation. </path/to/linux>/Documentation/driver-api/infrastructure:35: ./drivers/base/dd.c:281: WARNING: Block quote ends without a blank line; unexpected unindent. The warnings above is due to syntax error in the "Return" section of driver_deferred_probe_check_state() which messed up with desired line breaks. Fix the issue by using ReST lists syntax. Fixes: c8c43cee29f6ca ("driver core: Fix driver_deferred_probe_check_state() logic") Cc: linux-pm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Thierry Reding <treding(a)nvidia.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Cc: Saravana Kannan <saravanak(a)google.com> Cc: Todd Kjos <tkjos(a)google.com> Cc: Len Brown <len.brown(a)intel.com> Cc: Pavel Machek <pavel(a)ucw.cz> Cc: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Kevin Hilman <khilman(a)kernel.org> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Rob Herring <robh(a)kernel.org> Cc: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Bagas Sanjaya <bagasdotme(a)gmail.com> --- drivers/base/dd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 3fc3b5940bb..b0b410347ab 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -274,10 +274,10 @@ __setup("deferred_probe_timeout=", deferred_probe_timeout_setup); * @dev: device to check * * Return: - * -ENODEV if initcalls have completed and modules are disabled. - * -ETIMEDOUT if the deferred probe timeout was set and has expired - * and modules are enabled. - * -EPROBE_DEFER in other cases. + * * -ENODEV if initcalls have completed and modules are disabled. + * * -ETIMEDOUT if the deferred probe timeout was set and has expired + * and modules are enabled. + * * -EPROBE_DEFER in other cases. * * Drivers or subsystems can opt-in to calling this function instead of directly * returning -EPROBE_DEFER. base-commit: 59250f8a7f3a60a2661b84cbafc1e0eb5d05ec9b -- An old man doll... just what I always wanted! - Clara

3 years, 8 months

1
0
0 0

[PATCH] xtensa: fix a7 clobbering in coprocessor context load/store

by Max Filippov

Fast coprocessor exception handler saves a3..a6, but coprocessor context load/store code uses a4..a7 as temporaries, potentially clobbering a7. 'Potentially' because coprocessor state load/store macros may not use all four temporary registers (and neither FPU nor HiFi macros do). Use a3..a6 as intended. Cc: stable(a)vger.kernel.org Fixes: c658eac628aa ("[XTENSA] Add support for configurable registers and coprocessors") Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- arch/xtensa/kernel/coprocessor.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/xtensa/kernel/coprocessor.S b/arch/xtensa/kernel/coprocessor.S index 45cc0ae0af6f..c7b9f12896f2 100644 --- a/arch/xtensa/kernel/coprocessor.S +++ b/arch/xtensa/kernel/coprocessor.S @@ -29,7 +29,7 @@ .if XTENSA_HAVE_COPROCESSOR(x); \ .align 4; \ .Lsave_cp_regs_cp##x: \ - xchal_cp##x##_store a2 a4 a5 a6 a7; \ + xchal_cp##x##_store a2 a3 a4 a5 a6; \ jx a0; \ .endif @@ -46,7 +46,7 @@ .if XTENSA_HAVE_COPROCESSOR(x); \ .align 4; \ .Lload_cp_regs_cp##x: \ - xchal_cp##x##_load a2 a4 a5 a6 a7; \ + xchal_cp##x##_load a2 a3 a4 a5 a6; \ jx a0; \ .endif -- 2.30.2

3 years, 8 months

1
0
0 0

+ mm-hugetlbfs-allow-for-high-userspace-addresses.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm, hugetlb: allow for "high" userspace addresses has been added to the -mm tree. Its filename is mm-hugetlbfs-allow-for-high-userspace-addresses.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlbfs-allow-for-high-users… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlbfs-allow-for-high-users… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Christophe Leroy <christophe.leroy(a)csgroup.eu> Subject: mm, hugetlb: allow for "high" userspace addresses This is a fix for commit f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") for hugetlb. This patch adds support for "high" userspace addresses that are optionally supported on the system and have to be requested via a hint mechanism ("high" addr parameter to mmap). Architectures such as powerpc and x86 achieve this by making changes to their architectural versions of hugetlb_get_unmapped_area() function. However, arm64 uses the generic version of that function. So take into account arch_get_mmap_base() and arch_get_mmap_end() in hugetlb_get_unmapped_area(). To allow that, move those two macros out of mm/mmap.c into include/linux/sched/mm.h If these macros are not defined in architectural code then they default to (TASK_SIZE) and (base) so should not introduce any behavioural changes to architectures that do not define them. For the time being, only ARM64 is affected by this change. Catalin (ARM64) said : We should have fixed hugetlb_get_unmapped_area() as well when we added : support for 52-bit VA. The reason for commit f6795053dac8 was to prevent : normal mmap() from returning addresses above 48-bit by default as some : user-space had hard assumptions about this. : : It's a slight ABI change if you do this for hugetlb_get_unmapped_area() : but I doubt anyone would notice. It's more likely that the current : behaviour would cause issues, so I'd rather have them consistent. Link: https://lkml.kernel.org/r/ab847b6edb197bffdfe189e70fb4ac76bfe79e0d.16500337… Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Steve Capper <steve.capper(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: <stable(a)vger.kernel.org> [5.0.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/fs/hugetlbfs/inode.c~mm-hugetlbfs-allow-for-high-userspace-addresses +++ a/fs/hugetlbfs/inode.c @@ -206,7 +206,7 @@ hugetlb_get_unmapped_area_bottomup(struc info.flags = 0; info.length = len; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; return vm_unmapped_area(&info); @@ -222,7 +222,7 @@ hugetlb_get_unmapped_area_topdown(struct info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = max(PAGE_SIZE, mmap_min_addr); - info.high_limit = current->mm->mmap_base; + info.high_limit = arch_get_mmap_base(addr, current->mm->mmap_base); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; addr = vm_unmapped_area(&info); @@ -237,7 +237,7 @@ hugetlb_get_unmapped_area_topdown(struct VM_BUG_ON(addr != -ENOMEM); info.flags = 0; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr); addr = vm_unmapped_area(&info); } @@ -251,6 +251,7 @@ hugetlb_get_unmapped_area(struct file *f struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct hstate *h = hstate_file(file); + const unsigned long mmap_end = arch_get_mmap_end(addr); if (len & ~huge_page_mask(h)) return -EINVAL; @@ -266,7 +267,7 @@ hugetlb_get_unmapped_area(struct file *f if (addr) { addr = ALIGN(addr, huge_page_size(h)); vma = find_vma(mm, addr); - if (TASK_SIZE - len >= addr && + if (mmap_end - len >= addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } --- a/include/linux/sched/mm.h~mm-hugetlbfs-allow-for-high-userspace-addresses +++ a/include/linux/sched/mm.h @@ -136,6 +136,14 @@ static inline void mm_update_next_owner( #endif /* CONFIG_MEMCG */ #ifdef CONFIG_MMU +#ifndef arch_get_mmap_end +#define arch_get_mmap_end(addr) (TASK_SIZE) +#endif + +#ifndef arch_get_mmap_base +#define arch_get_mmap_base(addr, base) (base) +#endif + extern void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack); extern unsigned long --- a/mm/mmap.c~mm-hugetlbfs-allow-for-high-userspace-addresses +++ a/mm/mmap.c @@ -2117,14 +2117,6 @@ unsigned long vm_unmapped_area(struct vm return addr; } -#ifndef arch_get_mmap_end -#define arch_get_mmap_end(addr) (TASK_SIZE) -#endif - -#ifndef arch_get_mmap_base -#define arch_get_mmap_base(addr, base) (base) -#endif - /* Get an address range which is currently unmapped. * For shmat() with addr=0. * _ Patches currently in -mm which might be from christophe.leroy(a)csgroup.eu are mm-hugetlbfs-allow-for-high-userspace-addresses.patch

3 years, 8 months

1
0
0 0

stable-rc/queue/5.4 baseline: 128 runs, 4 regressions (v5.4.188-472-g2a5c061fe182a)

by kernelci.org bot

stable-rc/queue/5.4 baseline: 128 runs, 4 regressions (v5.4.188-472-g2a5c061fe182a) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -------------------------+------+--------------+----------+--------------------+------------ qemu_arm-virt-gicv2-uefi | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2-uefi | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3-uefi | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3-uefi | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.4/kernel/v5.4.188-… Test: baseline Tree: stable-rc Branch: queue/5.4 Describe: v5.4.188-472-g2a5c061fe182a URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 2a5c061fe182a528845cc9d00b0201b89274fd72 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -------------------------+------+--------------+----------+--------------------+------------ qemu_arm-virt-gicv2-uefi | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6259b5264465879bcfae06d7 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6259b5264465879bcfae06d8 failing since 120 days (last pass: v5.4.165-9-g27d736c7bdee, first fail: v5.4.165-18-ge938927511cb) platform | arch | lab | compiler | defconfig | regressions -------------------------+------+--------------+----------+--------------------+------------ qemu_arm-virt-gicv2-uefi | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6259b512c0f8fc05fdae068f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6259b512c0f8fc05fdae0690 failing since 120 days (last pass: v5.4.165-9-g27d736c7bdee, first fail: v5.4.165-18-ge938927511cb) platform | arch | lab | compiler | defconfig | regressions -------------------------+------+--------------+----------+--------------------+------------ qemu_arm-virt-gicv3-uefi | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6259b53cbc3e848d5eae067c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6259b53cbc3e848d5eae067d failing since 120 days (last pass: v5.4.165-9-g27d736c7bdee, first fail: v5.4.165-18-ge938927511cb) platform | arch | lab | compiler | defconfig | regressions -------------------------+------+--------------+----------+--------------------+------------ qemu_arm-virt-gicv3-uefi | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6259b5134465879bcfae067c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.188-472-g2a5c061fe18… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6259b5134465879bcfae067d failing since 120 days (last pass: v5.4.165-9-g27d736c7bdee, first fail: v5.4.165-18-ge938927511cb)

3 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022