- Linux-stable-mirror - lists.linaro.org

[PATCH 6.6 1/2] Revert "spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"

by jinfeng.wang.cn＠windriver.com

From: Jinfeng Wang <jinfeng.wang.cn(a)windriver.com> This reverts commit 1af6d1696ca40b2d22889b4b8bbea616f94aaa84. There is cadence-qspi ff8d2000.spi: Unbalanced pm_runtime_enable! error without this revert. After reverting commit cdfb20e4b34a ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 1af6d1696ca4 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), Unbalanced pm_runtime_enable! error does not appear. These two commits are backported from upstream commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"). The commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths") fix commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance"). The commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") fix commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"). The commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings") fix commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support"). 6.6.y only backport commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), but does not backport commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"). And the backport of commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") differs with the original patch. So there is Unbalanced pm_runtime_enable error. If revert the backport for commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), there is no error. If backport commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"), there is hang during booting. I didn't find the cause of the hang. Since commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings") are not backported, commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths") are not needed. So revert commits commit cdfb20e4b34a ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 1af6d1696ca4 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"). Signed-off-by: Jinfeng Wang <jinfeng.wang.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Kernel builds successfully with patch. Test enviroment overview: Branch linux-6.6.y Tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Hardware: compiled on X86 machine GCC: gcc version 11.4.0 (Ubuntu~20.04) commands: make clean;make allyesconfig; no building error is seen gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.2) Hardware: compiled on socfpga stratix10 board verified by check the dmesg log and bind/unbind spi and no Unbalanced pm_runtime_enable! error is seen any more. cmds: dmesg | grep "Unbalanced pm_runtime_enable" echo ff8d2000.spi > /sys/bus/platform/drivers/cadence-qspi/unbind echo ff8d2000.spi > /sys/bus/platform/drivers/cadence-qspi/bind --- drivers/spi/spi-cadence-quadspi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 7c17b8c0425e..9285a683324f 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1870,6 +1870,11 @@ static int cqspi_probe(struct platform_device *pdev) pm_runtime_enable(dev); + if (cqspi->rx_chan) { + dma_release_channel(cqspi->rx_chan); + goto probe_setup_failed; + } + ret = spi_register_controller(host); if (ret) { dev_err(&pdev->dev, "failed to register SPI ctlr %d\n", ret); -- 2.25.1

2 months

3
3
0 0

[PATCH] drivers/misc/amd-sbi/Kconfig: select REGMAP_I2C

by Max Kellermann

Without CONFIG_REGMAP, rmi-i2c.c fails to build because struct regmap_config is not defined: drivers/misc/amd-sbi/rmi-i2c.c: In function ‘sbrmi_i2c_probe’: drivers/misc/amd-sbi/rmi-i2c.c:57:16: error: variable ‘sbrmi_i2c_regmap_config’ has initializer but incomplete type 57 | struct regmap_config sbrmi_i2c_regmap_config = { | ^~~~~~~~~~~~~ Additionally, CONFIG_REGMAP_I2C is needed for devm_regmap_init_i2c(): ld: drivers/misc/amd-sbi/rmi-i2c.o: in function `sbrmi_i2c_probe': drivers/misc/amd-sbi/rmi-i2c.c:69:(.text+0x1c0): undefined reference to `__devm_regmap_init_i2c' Fixes: 013f7e7131bd ("misc: amd-sbi: Use regmap subsystem") Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- drivers/misc/amd-sbi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig index 4840831c84ca..4aae0733d0fc 100644 --- a/drivers/misc/amd-sbi/Kconfig +++ b/drivers/misc/amd-sbi/Kconfig @@ -2,6 +2,7 @@ config AMD_SBRMI_I2C tristate "AMD side band RMI support" depends on I2C + select REGMAP_I2C help Side band RMI over I2C support for AMD out of band management. -- 2.47.2

2 months

2
1
0 0

[merged mm-hotfixes-stable] mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/memory-failure: fix redundant updates for already poisoned pages has been removed from the -mm tree. Its filename was mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Kyle Meyer <kyle.meyer(a)hpe.com> Subject: mm/memory-failure: fix redundant updates for already poisoned pages Date: Thu, 28 Aug 2025 13:38:20 -0500 Duplicate memory errors can be reported by multiple sources. Passing an already poisoned page to action_result() causes issues: * The amount of hardware corrupted memory is incorrectly updated. * Per NUMA node MF stats are incorrectly updated. * Redundant "already poisoned" messages are printed. Avoid those issues by: * Skipping hardware corrupted memory updates for already poisoned pages. * Skipping per NUMA node MF stats updates for already poisoned pages. * Dropping redundant "already poisoned" messages. Make MF_MSG_ALREADY_POISONED consistent with other action_page_types and make calls to action_result() consistent for already poisoned normal pages and huge pages. Link: https://lkml.kernel.org/r/aLCiHMy12Ck3ouwC@hpe.com Fixes: b8b9488d50b7 ("mm/memory-failure: improve memory failure action_result messages") Signed-off-by: Kyle Meyer <kyle.meyer(a)hpe.com> Reviewed-by: Jiaqi Yan <jiaqiyan(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Jane Chu <jane.chu(a)oracle.com> Acked-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Kyle Meyer <kyle.meyer(a)hpe.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: "Luck, Tony" <tony.luck(a)intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Russ Anderson <russ.anderson(a)hpe.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages +++ a/mm/memory-failure.c @@ -956,7 +956,7 @@ static const char * const action_page_ty [MF_MSG_BUDDY] = "free buddy page", [MF_MSG_DAX] = "dax page", [MF_MSG_UNSPLIT_THP] = "unsplit thp", - [MF_MSG_ALREADY_POISONED] = "already poisoned", + [MF_MSG_ALREADY_POISONED] = "already poisoned page", [MF_MSG_UNKNOWN] = "unknown page", }; @@ -1349,9 +1349,10 @@ static int action_result(unsigned long p { trace_memory_failure_event(pfn, type, result); - num_poisoned_pages_inc(pfn); - - update_per_node_mf_stats(pfn, result); + if (type != MF_MSG_ALREADY_POISONED) { + num_poisoned_pages_inc(pfn); + update_per_node_mf_stats(pfn, result); + } pr_err("%#lx: recovery action for %s: %s\n", pfn, action_page_types[type], action_name[result]); @@ -2094,12 +2095,11 @@ retry: *hugetlb = 0; return 0; } else if (res == -EHWPOISON) { - pr_err("%#lx: already hardware poisoned\n", pfn); if (flags & MF_ACTION_REQUIRED) { folio = page_folio(p); res = kill_accessing_process(current, folio_pfn(folio), flags); - action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); } + action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); return res; } else if (res == -EBUSY) { if (!(flags & MF_NO_RETRY)) { @@ -2285,7 +2285,6 @@ try_again: goto unlock_mutex; if (TestSetPageHWPoison(p)) { - pr_err("%#lx: already hardware poisoned\n", pfn); res = -EHWPOISON; if (flags & MF_ACTION_REQUIRED) res = kill_accessing_process(current, pfn, flags); _ Patches currently in -mm which might be from kyle.meyer(a)hpe.com are

2 months

1
0
0 0

[merged mm-hotfixes-stable] s390-kexec-initialize-kexec_buf-struct.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: s390: kexec: initialize kexec_buf struct has been removed from the -mm tree. Its filename was s390-kexec-initialize-kexec_buf-struct.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: s390: kexec: initialize kexec_buf struct Date: Wed, 27 Aug 2025 03:42:23 -0700 The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-3-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Baoquan He <bhe(a)redhat.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/s390/kernel/kexec_elf.c | 2 +- arch/s390/kernel/kexec_image.c | 2 +- arch/s390/kernel/machine_kexec_file.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) --- a/arch/s390/kernel/kexec_elf.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/kexec_elf.c @@ -16,7 +16,7 @@ static int kexec_file_add_kernel_elf(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; const Elf_Ehdr *ehdr; const Elf_Phdr *phdr; Elf_Addr entry; --- a/arch/s390/kernel/kexec_image.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/kexec_image.c @@ -16,7 +16,7 @@ static int kexec_file_add_kernel_image(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; buf.image = image; --- a/arch/s390/kernel/machine_kexec_file.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/machine_kexec_file.c @@ -129,7 +129,7 @@ static int kexec_file_update_purgatory(s static int kexec_file_add_purgatory(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; int ret; buf.image = image; @@ -152,7 +152,7 @@ static int kexec_file_add_purgatory(stru static int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; int ret; buf.image = image; @@ -184,7 +184,7 @@ static int kexec_file_add_ipl_report(str { __u32 *lc_ipl_parmblock_ptr; unsigned int len, ncerts; - struct kexec_buf buf; + struct kexec_buf buf = {}; unsigned long addr; void *ptr, *end; int ret; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 months

1
0
0 0

[merged mm-hotfixes-stable] riscv-kexec-initialize-kexec_buf-struct.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: riscv: kexec: initialize kexec_buf struct has been removed from the -mm tree. Its filename was riscv-kexec-initialize-kexec_buf-struct.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: riscv: kexec: initialize kexec_buf struct Date: Wed, 27 Aug 2025 03:42:22 -0700 The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-2-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Baoquan He <bhe(a)redhat.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/riscv/kernel/kexec_elf.c | 4 ++-- arch/riscv/kernel/kexec_image.c | 2 +- arch/riscv/kernel/machine_kexec_file.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/riscv/kernel/kexec_elf.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/kexec_elf.c @@ -28,7 +28,7 @@ static int riscv_kexec_elf_load(struct k int i; int ret = 0; size_t size; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; const struct elf_phdr *phdr; kbuf.image = image; @@ -66,7 +66,7 @@ static int elf_find_pbase(struct kimage { int i; int ret; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; const struct elf_phdr *phdr; unsigned long lowest_paddr = ULONG_MAX; unsigned long lowest_vaddr = ULONG_MAX; --- a/arch/riscv/kernel/kexec_image.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *i struct riscv_image_header *h; u64 flags; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; int ret; /* Check Image header */ --- a/arch/riscv/kernel/machine_kexec_file.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/machine_kexec_file.c @@ -261,7 +261,7 @@ int load_extra_segments(struct kimage *i int ret; void *fdt; unsigned long initrd_pbase = 0UL; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; char *modified_cmdline = NULL; kbuf.image = image; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 months

1
0
0 0

[merged mm-hotfixes-stable] arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: arm64: kexec: initialize kexec_buf struct in load_other_segments() has been removed from the -mm tree. Its filename was arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: arm64: kexec: initialize kexec_buf struct in load_other_segments() Date: Wed, 27 Aug 2025 03:42:21 -0700 Patch series "kexec: Fix invalid field access". The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. An initial fix was already landed for arm64[0], and this patchset fixes the problem on the remaining arm64 code and on riscv, as raised by Mark. Discussions about this problem could be found at[1][2]. This patch (of 3): The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-0-1df9882bb01a@debian.org Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-1-1df9882bb01a@debian.org Link: https://lore.kernel.org/all/20250826180742.f2471131255ec1c43683ea07@linux-f… [0] Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnz… [1] Link: https://lore.kernel.org/all/20250826-akpm-v1-1-3c831f0e3799@debian.org/ [2] Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Acked-by: Baoquan He <bhe(a)redhat.com> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm64/kernel/machine_kexec_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/kernel/machine_kexec_file.c~arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments +++ a/arch/arm64/kernel/machine_kexec_file.c @@ -94,7 +94,7 @@ int load_other_segments(struct kimage *i char *initrd, unsigned long initrd_len, char *cmdline) { - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; void *dtb = NULL; unsigned long initrd_load_addr = 0, dtb_len, orig_segments = image->nr_segments; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 months

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-reclaim-avoid-divide-by-zero-in-damon_reclaim_apply_parameters.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() has been removed from the -mm tree. Its filename was mm-damon-reclaim-avoid-divide-by-zero-in-damon_reclaim_apply_parameters.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Quanmin Yan <yanquanmin1(a)huawei.com> Subject: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() Date: Wed, 27 Aug 2025 19:58:58 +0800 When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Link: https://lkml.kernel.org/r/20250827115858.1186261-3-yanquanmin1@huawei.com Fixes: f5a79d7c0c87 ("mm/damon: introduce struct damos_access_pattern") Signed-off-by: Quanmin Yan <yanquanmin1(a)huawei.com> Reviewed-by: SeongJae Park <sj(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: ze zuo <zuoze1(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.1+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/reclaim.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/mm/damon/reclaim.c~mm-damon-reclaim-avoid-divide-by-zero-in-damon_reclaim_apply_parameters +++ a/mm/damon/reclaim.c @@ -194,6 +194,11 @@ static int damon_reclaim_apply_parameter if (err) return err; + if (!damon_reclaim_mon_attrs.aggr_interval) { + err = -EINVAL; + goto out; + } + err = damon_set_attrs(param_ctx, &damon_reclaim_mon_attrs); if (err) goto out; _ Patches currently in -mm which might be from yanquanmin1(a)huawei.com are mm-damon-add-damon_ctx-min_sz_region.patch

2 months

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-lru_sort-avoid-divide-by-zero-in-damon_lru_sort_apply_parameters.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() has been removed from the -mm tree. Its filename was mm-damon-lru_sort-avoid-divide-by-zero-in-damon_lru_sort_apply_parameters.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Quanmin Yan <yanquanmin1(a)huawei.com> Subject: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() Date: Wed, 27 Aug 2025 19:58:57 +0800 Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application". DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors. Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters. This patch (of 2): During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked. Link: https://lkml.kernel.org/r/20250827115858.1186261-2-yanquanmin1@huawei.com Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting") Signed-off-by: Quanmin Yan <yanquanmin1(a)huawei.com> Reviewed-by: SeongJae Park <sj(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: ze zuo <zuoze1(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.0+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/lru_sort.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/mm/damon/lru_sort.c~mm-damon-lru_sort-avoid-divide-by-zero-in-damon_lru_sort_apply_parameters +++ a/mm/damon/lru_sort.c @@ -198,6 +198,11 @@ static int damon_lru_sort_apply_paramete if (err) return err; + if (!damon_lru_sort_mon_attrs.sample_interval) { + err = -EINVAL; + goto out; + } + err = damon_set_attrs(ctx, &damon_lru_sort_mon_attrs); if (err) goto out; _ Patches currently in -mm which might be from yanquanmin1(a)huawei.com are mm-damon-add-damon_ctx-min_sz_region.patch

2 months

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: set quota->charged_from to jiffies at first charge window has been removed from the -mm tree. Its filename was mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Sang-Heon Jeon <ekffu200098(a)gmail.com> Subject: mm/damon/core: set quota->charged_from to jiffies at first charge window Date: Fri, 22 Aug 2025 11:50:57 +0900 Kernel initializes the "jiffies" timer as 5 minutes below zero, as shown in include/linux/jiffies.h /* * Have the 32 bit jiffies value wrap 5 minutes after boot * so jiffies wrap bugs show up earlier. */ #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ)) And jiffies comparison help functions cast unsigned value to signed to cover wraparound #define time_after_eq(a,b) \ (typecheck(unsigned long, a) && \ typecheck(unsigned long, b) && \ ((long)((a) - (b)) >= 0)) When quota->charged_from is initialized to 0, time_after_eq() can incorrectly return FALSE even after reset_interval has elapsed. This occurs when (jiffies - reset_interval) produces a value with MSB=1, which is interpreted as negative in signed arithmetic. This issue primarily affects 32-bit systems because: On 64-bit systems: MSB=1 values occur after ~292 million years from boot (assuming HZ=1000), almost impossible. On 32-bit systems: MSB=1 values occur during the first 5 minutes after boot, and the second half of every jiffies wraparound cycle, starting from day 25 (assuming HZ=1000) When above unexpected FALSE return from time_after_eq() occurs, the charging window will not reset. The user impact depends on esz value at that time. If esz is 0, scheme ignores configured quotas and runs without any limits. If esz is not 0, scheme stops working once the quota is exhausted. It remains until the charging window finally resets. So, change quota->charged_from to jiffies at damos_adjust_quota() when it is considered as the first charge window. By this change, we can avoid unexpected FALSE return from time_after_eq() Link: https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com Fixes: 2b8a248d5873 ("mm/damon/schemes: implement size quota for schemes application speed control") # 5.16 Signed-off-by: Sang-Heon Jeon <ekffu200098(a)gmail.com> Reviewed-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/mm/damon/core.c~mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window +++ a/mm/damon/core.c @@ -2111,6 +2111,10 @@ static void damos_adjust_quota(struct da if (!quota->ms && !quota->sz && list_empty(&quota->goals)) return; + /* First charge window */ + if (!quota->total_charged_sz && !quota->charged_from) + quota->charged_from = jiffies; + /* New charge window starts */ if (time_after_eq(jiffies, quota->charged_from + msecs_to_jiffies(quota->reset_interval))) { _ Patches currently in -mm which might be from ekffu200098(a)gmail.com are mm-damon-update-expired-description-of-damos_action.patch docs-mm-damon-design-fix-typo-s-sz_trtied-sz_tried.patch selftests-damon-test-no-op-commit-broke-damon-status.patch selftests-damon-test-no-op-commit-broke-damon-status-fix.patch mm-damon-tests-core-kunit-add-damos_commit_filter-test.patch

2 months

1
0
0 0

[merged mm-hotfixes-stable] mm-hugetlb-add-missing-hugetlb_lock-in-__unmap_hugepage_range.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: add missing hugetlb_lock in __unmap_hugepage_range() has been removed from the -mm tree. Its filename was mm-hugetlb-add-missing-hugetlb_lock-in-__unmap_hugepage_range.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jeongjun Park <aha310510(a)gmail.com> Subject: mm/hugetlb: add missing hugetlb_lock in __unmap_hugepage_range() Date: Sun, 24 Aug 2025 03:21:15 +0900 When restoring a reservation for an anonymous page, we need to check to freeing a surplus. However, __unmap_hugepage_range() causes data race because it reads h->surplus_huge_pages without the protection of hugetlb_lock. And adjust_reservation is a boolean variable that indicates whether reservations for anonymous pages in each folio should be restored. Therefore, it should be initialized to false for each round of the loop. However, this variable is not initialized to false except when defining the current adjust_reservation variable. This means that once adjust_reservation is set to true even once within the loop, reservations for anonymous pages will be restored unconditionally in all subsequent rounds, regardless of the folio's state. To fix this, we need to add the missing hugetlb_lock, unlock the page_table_lock earlier so that we don't lock the hugetlb_lock inside the page_table_lock lock, and initialize adjust_reservation to false on each round within the loop. Link: https://lkml.kernel.org/r/20250823182115.1193563-1-aha310510@gmail.com Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> Reported-by: syzbot+417aeb05fd190f3a6da9(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=417aeb05fd190f3a6da9 Reviewed-by: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Cc: Breno Leitao <leitao(a)debian.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-add-missing-hugetlb_lock-in-__unmap_hugepage_range +++ a/mm/hugetlb.c @@ -5851,7 +5851,7 @@ void __unmap_hugepage_range(struct mmu_g spinlock_t *ptl; struct hstate *h = hstate_vma(vma); unsigned long sz = huge_page_size(h); - bool adjust_reservation = false; + bool adjust_reservation; unsigned long last_addr_mask; bool force_flush = false; @@ -5944,6 +5944,7 @@ void __unmap_hugepage_range(struct mmu_g sz); hugetlb_count_sub(pages_per_huge_page(h), mm); hugetlb_remove_rmap(folio); + spin_unlock(ptl); /* * Restore the reservation for anonymous page, otherwise the @@ -5951,14 +5952,16 @@ void __unmap_hugepage_range(struct mmu_g * If there we are freeing a surplus, do not set the restore * reservation bit. */ + adjust_reservation = false; + + spin_lock_irq(&hugetlb_lock); if (!h->surplus_huge_pages && __vma_private_lock(vma) && folio_test_anon(folio)) { folio_set_hugetlb_restore_reserve(folio); /* Reservation to be adjusted after the spin lock */ adjust_reservation = true; } - - spin_unlock(ptl); + spin_unlock_irq(&hugetlb_lock); /* * Adjust the reservation for the region that will have the _ Patches currently in -mm which might be from aha310510(a)gmail.com are

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror