August 2025 - Linux-stable-mirror

+ mm-move-page-table-sync-declarations-to-linux-pgtableh.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: move page table sync declarations to linux/pgtable.h has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-move-page-table-sync-declarations-to-linux-pgtableh.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Harry Yoo <harry.yoo(a)oracle.com> Subject: mm: move page table sync declarations to linux/pgtable.h Date: Mon, 18 Aug 2025 11:02:04 +0900 During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by this patch series. This series was hugely inspired by Dave Hansen's suggestion and hence added Suggested-by: Dave Hansen. Cc stable because lack of this series opens the door to intermittent boot failures. This patch (of 3): Move ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to linux/pgtable.h so that they can be used outside of vmalloc and ioremap. Link: https://lkml.kernel.org/r/20250818020206.4517-1-harry.yoo@oracle.com Link: https://lkml.kernel.org/r/20250818020206.4517-2-harry.yoo@oracle.com Link: https://lore.kernel.org/linux-mm/20250220064105.808339-1-gwan-gyeong.mun@in… [1] Link: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@in… [2] Link: https://lore.kernel.org/linux-mm/d1da214c-53d3-45ac-a8b6-51821c5416e4@intel… [3] Link: https://lore.kernel.org/linux-mm/4d800744-7b88-41aa-9979-b245e8bf794b@intel… [4] Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> Acked-by: Kiryl Shutsemau <kas(a)kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Alistair Popple <apopple(a)nvidia.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: bibo mao <maobibo(a)loongson.cn> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Christoph Lameter (Ampere) <cl(a)gentwo.org> Cc: Dennis Zhou <dennis(a)kernel.org> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun(a)intel.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jane Chu <jane.chu(a)oracle.com> Cc: Joao Martins <joao.m.martins(a)oracle.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Kevin Brodsky <kevin.brodsky(a)arm.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Peter Xu <peterx(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Qi Zheng <zhengqi.arch(a)bytedance.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: Thomas Huth <thuth(a)redhat.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/pgtable.h | 16 ++++++++++++++++ include/linux/vmalloc.h | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) --- a/include/linux/pgtable.h~mm-move-page-table-sync-declarations-to-linux-pgtableh +++ a/include/linux/pgtable.h @@ -1467,6 +1467,22 @@ static inline void modify_prot_commit_pt } #endif +/* + * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values + * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings() + * needs to be called. + */ +#ifndef ARCH_PAGE_TABLE_SYNC_MASK +#define ARCH_PAGE_TABLE_SYNC_MASK 0 +#endif + +/* + * There is no default implementation for arch_sync_kernel_mappings(). It is + * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK + * is 0. + */ +void arch_sync_kernel_mappings(unsigned long start, unsigned long end); + #endif /* CONFIG_MMU */ /* --- a/include/linux/vmalloc.h~mm-move-page-table-sync-declarations-to-linux-pgtableh +++ a/include/linux/vmalloc.h @@ -220,22 +220,6 @@ int vmap_pages_range(unsigned long addr, struct page **pages, unsigned int page_shift); /* - * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values - * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings() - * needs to be called. - */ -#ifndef ARCH_PAGE_TABLE_SYNC_MASK -#define ARCH_PAGE_TABLE_SYNC_MASK 0 -#endif - -/* - * There is no default implementation for arch_sync_kernel_mappings(). It is - * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK - * is 0. - */ -void arch_sync_kernel_mappings(unsigned long start, unsigned long end); - -/* * Lowlevel-APIs (not for driver use!) */ _ Patches currently in -mm which might be from harry.yoo(a)oracle.com are mm-move-page-table-sync-declarations-to-linux-pgtableh.patch mm-introduce-and-use-pgdp4d_populate_kernel.patch x86-mm-64-define-arch_page_table_sync_mask-and-arch_sync_kernel_mappings.patch

2 months, 2 weeks

1
0
0 0

+ of_numa-fix-uninitialized-memory-nodes-causing-kernel-panic.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: of_numa: fix uninitialized memory nodes causing kernel panic has been added to the -mm mm-hotfixes-unstable branch. Its filename is of_numa-fix-uninitialized-memory-nodes-causing-kernel-panic.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Yin Tirui <yintirui(a)huawei.com> Subject: of_numa: fix uninitialized memory nodes causing kernel panic Date: Tue, 19 Aug 2025 15:55:10 +0800 When there are memory-only nodes (nodes without CPUs), these nodes are not properly initialized, causing kernel panic during boot. of_numa_init of_numa_parse_cpu_nodes node_set(nid, numa_nodes_parsed); of_numa_parse_memory_nodes In of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes containing CPUs. Memory-only nodes should have been updated in of_numa_parse_memory_nodes, but they weren't. Subsequently, when free_area_init() attempts to access NODE_DATA() for these uninitialized memory nodes, the kernel panics due to NULL pointer dereference. This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes: qemu-system-aarch64 \ -cpu host -nographic \ -m 4G -smp 1 \ -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \ -object memory-backend-ram,size=2G,id=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=0,memdev=mem0 \ -numa node,nodeid=1,memdev=mem1 \ -kernel $IMAGE \ -hda $DISK \ -append "console=ttyAMA0 root=/dev/vda rw earlycon" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010] [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025 [ 0.000000] KASLR enabled [ 0.000000] random: crng init done [ 0.000000] Machine model: linux,dummy-virt [ 0.000000] efi: UEFI not found. [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '') [ 0.000000] printk: legacy bootconsole [pl11] enabled [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT [ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff] [ 0.000000] node 1 must be removed before remove section 23 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 0.000000] Mem abort info: [ 0.000000] ESR = 0x0000000096000004 [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.000000] SET = 0, FnV = 0 [ 0.000000] EA = 0, S1PTW = 0 [ 0.000000] FSC = 0x04: level 0 translation fault [ 0.000000] Data abort info: [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.000000] [00000000000000a0] user address but active_mm is swapper [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : free_area_init+0x50c/0xf9c [ 0.000000] lr : free_area_init+0x5c0/0xf9c [ 0.000000] sp : ffffa02ca0f33c00 [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000 [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000 [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368 [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002 [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001 [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002 [ 0.000000] x11: ffffa02ca0fd4f00 x10: ffffa02ca14bab20 x9 : ffffa02ca14bab38 [ 0.000000] x8 : 00000000000c0000 x7 : 0000000000000001 x6 : 0000000000000002 [ 0.000000] x5 : 0000000140000000 x4 : ffffa02ca0f33c90 x3 : ffffa02ca0f33ca0 [ 0.000000] x2 : ffffa02ca0f33c98 x1 : 0000000080000000 x0 : 0000000000000001 [ 0.000000] Call trace: [ 0.000000] free_area_init+0x50c/0xf9c (P) [ 0.000000] bootmem_init+0x110/0x1dc [ 0.000000] setup_arch+0x278/0x60c [ 0.000000] start_kernel+0x70/0x748 [ 0.000000] __primary_switched+0x88/0x90 [ 0.000000] Code: d503201f b98093e0 52800016 f8607a93 (f9405260) [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Link: https://lkml.kernel.org/r/20250819075510.2079961-1-yintirui@huawei.com Fixes: 767507654c22 ("arch_numa: switch over to numa_memblks") Signed-off-by: Yin Tirui <yintirui(a)huawei.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Chen Jun <chenjun102(a)huawei.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Joanthan Cameron <Jonathan.Cameron(a)huawei.com> Cc: Rob Herring <robh(a)kernel.org> Cc: Saravana Kannan <saravanak(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/of/of_numa.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/of/of_numa.c~of_numa-fix-uninitialized-memory-nodes-causing-kernel-panic +++ a/drivers/of/of_numa.c @@ -59,8 +59,11 @@ static int __init of_numa_parse_memory_n r = -EINVAL; } - for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++) + for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++) { r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1); + if (!r) + node_set(nid, numa_nodes_parsed); + } if (!i || r) { of_node_put(np); _ Patches currently in -mm which might be from yintirui(a)huawei.com are of_numa-fix-uninitialized-memory-nodes-causing-kernel-panic.patch

2 months, 2 weeks

1
0
0 0

[PATCH v5 0/5] i2c: rtl9300: Fix multi-byte I2C operations

by Sven Eckelmann

During the integration of the RTL8239 POE chip + its frontend MCU, it was noticed that multi-byte operations were basically broken in the current driver. Tests using SMBus Block Writes showed that the data (after the Wr maker + Ack) was mixed up on the wire. At first glance, it looked like an endianness problem. But for transfers where the number of count + data bytes was not divisible by 4, the last bytes were not looking like an endianness problem because they were in the wrong order but not for example 0 - which would be the case for an endianness problem with 32 bit registers. At the end, it turned out to be the way how i2c_write tried to add the bytes to the send registers. Each 32 bit register was used similar to a shift register - shifting the various bytes up the register while the next one is added to the least significant byte. But the I2C controller expects the first byte of the transmission in the least significant byte of the first register. And the last byte (assuming it is a 16 byte transfer) is expected in the most significant byte of the fourth register. While doing these tests, it was also observed that the count byte was missing from the SMBus Block Writes. The driver just removed them from the data->block (from the I2C subsystem). But the I2C controller DOES NOT automatically add this byte - for example by using the configured transmission length. The RTL8239 MCU is not actually an SMBus compliant device. Instead, it expects I2C Block Reads + I2C Block Writes. But according to the already identified bugs in the driver, it was clear that the I2C controller can simply be modified to not send the count byte for I2C_SMBUS_I2C_BLOCK_DATA. The receive part just needs to write the content of the receive buffer to the correct position in data->block. While the on-wire format was now correct, reads were still not possible against the MCU (for the RTL8239 POE chip). It was always timing out because the 2ms were not enough for sending the read request and then receiving the 12 byte answer. These changes were originally submitted to OpenWrt. But there are plans to migrate OpenWrt to the upstream Linux driver. As a result, the pull request was stopped and the changes were redone against this driver. For reasons of transparency: The work on I2C_SMBUS_I2C_BLOCK_DATA support for the RTL8239-MCU was done on RTL931xx. All problems were therefore detected with the patches from Jonas Jelonek [1] and not the vanilla Linux driver. But looking through the code, it seems like these are NOT regressions introduced by the RTL931x patchset. I've picked up Alex Guo's patch [2] to reduce conflicts between pending fixes. [1] https://patchwork.ozlabs.org/project/linux-i2c/cover/20250727114800.3046-1-… [2] https://lore.kernel.org/r/20250615235248.529019-1-alexguo1023@gmail.com Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Changes in v5: - Simplify function/capability registration by using I2C_FUNC_SMBUS_I2C_BLOCK, thanks Jonas Jelonek - Link to v4: https://lore.kernel.org/r/20250809-i2c-rtl9300-multi-byte-v4-0-d71dd5eb6121… Changes in v4: - Provide only "write" examples for "i2c: rtl9300: Fix multi-byte I2C write" - drop the second initialization of vals in rtl9300_i2c_write() directly in the "Fix multi-byte I2C write" fix - indicate in target branch for each patch in PATCH prefix - minor commit message cleanups - Link to v3: https://lore.kernel.org/r/20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c… Changes in v3: - integrated patch https://lore.kernel.org/r/20250615235248.529019-1-alexguo1023@gmail.com to avoid conflicts in the I2C_SMBUS_BLOCK_DATA code - added Fixes and stable(a)vger.kernel.org to Alex Guo's patch - added Chris Packham's Reviewed-by/Acked-by - Link to v2: https://lore.kernel.org/r/20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6… Changes in v2: - add the missing transfer width and read length increase for the SMBus Write/Read - Link to v1: https://lore.kernel.org/r/20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2… --- Alex Guo (1): i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer Harshal Gohel (2): [i2c-host-fixes] i2c: rtl9300: Fix multi-byte I2C write [i2c-host] i2c: rtl9300: Implement I2C block read and write Sven Eckelmann (2): [i2c-host-fixes] i2c: rtl9300: Increase timeout for transfer polling [i2c-host-fixes] i2c: rtl9300: Add missing count byte for SMBus Block Ops drivers/i2c/busses/i2c-rtl9300.c | 51 +++++++++++++++++++++++++++++++++------- 1 file changed, 42 insertions(+), 9 deletions(-) --- base-commit: 7e161a991ea71e6ec526abc8f40c6852ebe3d946 change-id: 20250802-i2c-rtl9300-multi-byte-edaa1fb0872c Best regards, -- Sven Eckelmann <sven(a)narfation.org>

2 months, 2 weeks

2
5
0 0

+ mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/damon/core: set quota->charged_from to jiffies at first charge window has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sang-Heon Jeon <ekffu200098(a)gmail.com> Subject: mm/damon/core: set quota->charged_from to jiffies at first charge window Date: Wed, 20 Aug 2025 00:01:23 +0900 Kernel initializes "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 they 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)) In 64bit systems, these might not be a problem because wrapround occurs 300 million years after the boot, assuming HZ value is 1000. With same assuming, In 32bit system, wraparound occurs 5 minutues after the initial boot and every 49 days after the first wraparound. And about 25 days after first wraparound, it continues quota charging window up to next 25 days. Example 1: initial boot jiffies=0xFFFB6C20, charged_from+interval=0x000003E8 time_after_eq(jiffies, charged_from+interval)=(long)0xFFFB6838; In signed values, it is considered negative so it is false. Example 2: after about 25 days first wraparound jiffies=0x800004E8, charged_from+interval=0x000003E8 time_after_eq(jiffies, charged_from+interval)=(long)0x80000100; In signed values, it is considered negative so it is false So, change quota->charged_from to jiffies at damos_adjust_quota() when it is consider first charge window. In theory; but almost impossible; quota->total_charged_sz and qutoa->charged_from should be both zero even if it is not in first charge window. But It will only delay one reset_interval, So it is not big problem. Link: https://lkml.kernel.org/r/20250819150123.1532458-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-core-fix-commit_ops_filters-by-using-correct-nth-function.patch selftests-damon-fix-selftests-by-installing-drgn-related-script.patch mm-damon-core-fix-damos_commit_filter-not-changing-allow.patch mm-damon-core-set-quota-charged_from-to-jiffies-at-first-charge-window.patch 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, 2 weeks

1
0
0 0

[PATCH AUTOSEL 6.16] io_uring/io-wq: add check free worker before create new worker

by Sasha Levin

From: Fengnan Chang <changfengnan(a)bytedance.com> [ Upstream commit 9d83e1f05c98bab5de350bef89177e2be8b34db0 ] After commit 0b2b066f8a85 ("io_uring/io-wq: only create a new worker if it can make progress"), in our produce environment, we still observe that part of io_worker threads keeps creating and destroying. After analysis, it was confirmed that this was due to a more complex scenario involving a large number of fsync operations, which can be abstracted as frequent write + fsync operations on multiple files in a single uring instance. Since write is a hash operation while fsync is not, and fsync is likely to be suspended during execution, the action of checking the hash value in io_wqe_dec_running cannot handle such scenarios. Similarly, if hash-based work and non-hash-based work are sent at the same time, similar issues are likely to occur. Returning to the starting point of the issue, when a new work arrives, io_wq_enqueue may wake up free worker A, while io_wq_dec_running may create worker B. Ultimately, only one of A and B can obtain and process the task, leaving the other in an idle state. In the end, the issue is caused by inconsistent logic in the checks performed by io_wq_enqueue and io_wq_dec_running. Therefore, the problem can be resolved by checking for available workers in io_wq_dec_running. Signed-off-by: Fengnan Chang <changfengnan(a)bytedance.com> Reviewed-by: Diangang Li <lidiangang(a)bytedance.com> Link: https://lore.kernel.org/r/20250813120214.18729-1-changfengnan@bytedance.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Now let me analyze the nature of the fix to determine if it's appropriate for stable: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: ## Bug Fix Nature The commit fixes a **real performance bug** that occurs in production environments. The issue causes unnecessary creation and destruction of io_worker threads, leading to: 1. CPU overhead from constant thread creation/destruction 2. Resource wastage from redundant workers 3. Performance degradation in production workloads with mixed hash/non- hash operations ## Root Cause Analysis The patch addresses a **race condition** between `io_wq_enqueue()` and `io_wq_dec_running()`: - When new work arrives, `io_wq_enqueue()` may wake up a free worker A - Simultaneously, `io_wq_dec_running()` may create a new worker B - Only one worker can actually process the task, leaving the other idle - This creates a worker "churn" pattern that wastes resources ## Small and Contained Fix The fix is minimal and surgical: 1. Adds a check in `create_worker_cb()` to verify if a free worker is available before creating a new one 2. Uses the existing `io_acct_activate_free_worker()` function (lines 361-365) 3. Only adds 8 lines of code with proper RCU locking 4. Introduces a single goto label for clean error handling ## Production Impact The commit message explicitly states this was observed in **production environments** with real workloads involving: - Frequent write + fsync operations - Mixed hash and non-hash operations - Multiple files in a single io_uring instance ## Regression Potential The fix has **low regression risk** because: 1. It reuses existing, well-tested infrastructure (`io_acct_activate_free_worker()`) 2. The logic is consistent with what `io_wq_enqueue()` already does 3. It adds a defensive check rather than changing core logic 4. The RCU locking is properly scoped and follows existing patterns ## Stable Kernel Rules Compliance The patch follows stable kernel criteria: - ✓ Fixes a real bug affecting users (worker thread churn in production) - ✓ Small change (8 lines added) - ✓ Obviously correct (aligns logic between enqueue and dec_running paths) - ✓ Already tested in production (reported by ByteDance engineers) - ✓ Not a new feature or optimization ## Affected Versions This should be backported to kernels containing commit 0b2b066f8a85 ("io_uring/io-wq: only create a new worker if it can make progress") which introduced incomplete handling of the worker creation logic. The issue affects mixed workload scenarios that are common in production environments. The fact that this was discovered and reported by engineers from a major cloud provider (ByteDance) running production workloads further validates its importance for stable backporting. io_uring/io-wq.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c index be91edf34f01..17dfaa0395c4 100644 --- a/io_uring/io-wq.c +++ b/io_uring/io-wq.c @@ -357,6 +357,13 @@ static void create_worker_cb(struct callback_head *cb) worker = container_of(cb, struct io_worker, create_work); wq = worker->wq; acct = worker->acct; + + rcu_read_lock(); + do_create = !io_acct_activate_free_worker(acct); + rcu_read_unlock(); + if (!do_create) + goto no_need_create; + raw_spin_lock(&acct->workers_lock); if (acct->nr_workers < acct->max_workers) { @@ -367,6 +374,7 @@ static void create_worker_cb(struct callback_head *cb) if (do_create) { create_io_worker(wq, acct); } else { +no_need_create: atomic_dec(&acct->nr_running); io_worker_ref_put(wq); } -- 2.50.1

2 months, 2 weeks

1
8
0 0

[PATCH] drm/amd/display: fix leak of probed modes

by Fedor Pchelkin

amdgpu_dm_connector_ddc_get_modes() reinitializes a connector's probed modes list without cleaning it up. First time it is called during the driver's initialization phase, then via drm_mode_getconnector() ioctl. The leaks observed with Kmemleak are as following: unreferenced object 0xffff88812f91b200 (size 128): comm "(udev-worker)", pid 388, jiffies 4294695475 hex dump (first 32 bytes): ac dd 07 00 80 02 70 0b 90 0b e0 0b 00 00 e0 01 ......p......... 0b 07 10 07 5c 07 00 00 0a 00 00 00 00 00 00 00 ....\........... backtrace (crc 89db554f): __kmalloc_cache_noprof+0x3a3/0x490 drm_mode_duplicate+0x8e/0x2b0 amdgpu_dm_create_common_mode+0x40/0x150 [amdgpu] amdgpu_dm_connector_add_common_modes+0x336/0x488 [amdgpu] amdgpu_dm_connector_get_modes+0x428/0x8a0 [amdgpu] amdgpu_dm_initialize_drm_device+0x1389/0x17b4 [amdgpu] amdgpu_dm_init.cold+0x157b/0x1a1e [amdgpu] dm_hw_init+0x3f/0x110 [amdgpu] amdgpu_device_ip_init+0xcf4/0x1180 [amdgpu] amdgpu_device_init.cold+0xb84/0x1863 [amdgpu] amdgpu_driver_load_kms+0x15/0x90 [amdgpu] amdgpu_pci_probe+0x391/0xce0 [amdgpu] local_pci_probe+0xd9/0x190 pci_call_probe+0x183/0x540 pci_device_probe+0x171/0x2c0 really_probe+0x1e1/0x890 Found by Linux Verification Center (linuxtesting.org). Fixes: acc96ae0d127 ("drm/amd/display: set panel orientation before drm_dev_register") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- I can't reproduce the issue before the commit in Fixes which placed that extra amdgpu_dm_connector_get_modes() call. Though the reinitializing part /* empty probed_modes */ INIT_LIST_HEAD(&connector->probed_modes); was added years before and it looks OK since drm_connector_list_update() should shake the list in between drm_mode_getconnector() ioctl calls. For what the patch does there exists a drm_mode_remove() helper but it's static at drivers/gpu/drm/drm_connector.c and requires to be exported first. This probably looks like a subject for an independent for-next patch, if needed. drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index cd0e2976e268..4b84f944f066 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8227,9 +8227,14 @@ static void amdgpu_dm_connector_ddc_get_modes(struct drm_connector *connector, { struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector); + struct drm_display_mode *mode, *t; if (drm_edid) { /* empty probed_modes */ + list_for_each_entry_safe(mode, t, &connector->probed_modes, head) { + list_del(&mode->head); + drm_mode_destroy(connector->dev, mode); + } INIT_LIST_HEAD(&connector->probed_modes); amdgpu_dm_connector->num_modes = drm_edid_connector_add_modes(connector); -- 2.50.1

2 months, 2 weeks

2
2
0 0

FAILED: patch "[PATCH] mm/kmemleak: avoid deadlock by moving pr_warn() outside" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 47b0f6d8f0d2be4d311a49e13d2fd5f152f492b2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081848-proximity-feline-dfea@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 47b0f6d8f0d2be4d311a49e13d2fd5f152f492b2 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Thu, 31 Jul 2025 02:57:18 -0700 Subject: [PATCH] mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags); Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released. Link: https://lkml.kernel.org/r/20250731-kmemleak_lock-v1-1-728fd470198f@debian.o… Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early allocations") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reported-by: Jakub Kicinski <kuba(a)kernel.org> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 8d588e685311..e0333455c738 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -470,6 +470,7 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t gfp) { unsigned long flags; struct kmemleak_object *object; + bool warn = false; /* try the slab allocator first */ if (object_cache) { @@ -488,8 +489,10 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t gfp) else if (mem_pool_free_count) object = &mem_pool[--mem_pool_free_count]; else - pr_warn_once("Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE\n"); + warn = true; raw_spin_unlock_irqrestore(&kmemleak_lock, flags); + if (warn) + pr_warn_once("Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE\n"); return object; }

2 months, 2 weeks

2
2
0 0

FAILED: patch "[PATCH] media: venus: Fix OOB read due to missing payload bound check" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 06d6770ff0d8cc8dfd392329a8cc03e2a83e7289 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081854-pauper-opacity-6318@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 06d6770ff0d8cc8dfd392329a8cc03e2a83e7289 Mon Sep 17 00:00:00 2001 From: Vedang Nagar <quic_vnagar(a)quicinc.com> Date: Mon, 19 May 2025 12:42:22 +0530 Subject: [PATCH] media: venus: Fix OOB read due to missing payload bound check Currently, The event_seq_changed() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length. This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed. Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed. This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior. Fixes: 09c2845e8fe4 ("[media] media: venus: hfi: add Host Firmware Interface (HFI)") Cc: stable(a)vger.kernel.org Signed-off-by: Vedang Nagar <quic_vnagar(a)quicinc.com> Reviewed-by: Vikash Garodia <quic_vgarodia(a)quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> Co-developed-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> Signed-off-by: Bryan O'Donoghue <bod(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil(a)xs4all.nl> diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c b/drivers/media/platform/qcom/venus/hfi_msgs.c index 0a041b4db9ef..cf0d97cbc463 100644 --- a/drivers/media/platform/qcom/venus/hfi_msgs.c +++ b/drivers/media/platform/qcom/venus/hfi_msgs.c @@ -33,8 +33,9 @@ static void event_seq_changed(struct venus_core *core, struct venus_inst *inst, struct hfi_buffer_requirements *bufreq; struct hfi_extradata_input_crop *crop; struct hfi_dpb_counts *dpb_count; + u32 ptype, rem_bytes; + u32 size_read = 0; u8 *data_ptr; - u32 ptype; inst->error = HFI_ERR_NONE; @@ -44,86 +45,118 @@ static void event_seq_changed(struct venus_core *core, struct venus_inst *inst, break; default: inst->error = HFI_ERR_SESSION_INVALID_PARAMETER; - goto done; + inst->ops->event_notify(inst, EVT_SYS_EVENT_CHANGE, &event); + return; } event.event_type = pkt->event_data1; num_properties_changed = pkt->event_data2; - if (!num_properties_changed) { - inst->error = HFI_ERR_SESSION_INSUFFICIENT_RESOURCES; - goto done; - } + if (!num_properties_changed) + goto error; data_ptr = (u8 *)&pkt->ext_event_data[0]; + rem_bytes = pkt->shdr.hdr.size - sizeof(*pkt); + do { + if (rem_bytes < sizeof(u32)) + goto error; ptype = *((u32 *)data_ptr); + + data_ptr += sizeof(u32); + rem_bytes -= sizeof(u32); + switch (ptype) { case HFI_PROPERTY_PARAM_FRAME_SIZE: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_framesize)) + goto error; + frame_sz = (struct hfi_framesize *)data_ptr; event.width = frame_sz->width; event.height = frame_sz->height; - data_ptr += sizeof(*frame_sz); + size_read = sizeof(struct hfi_framesize); break; case HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_profile_level)) + goto error; + profile_level = (struct hfi_profile_level *)data_ptr; event.profile = profile_level->profile; event.level = profile_level->level; - data_ptr += sizeof(*profile_level); + size_read = sizeof(struct hfi_profile_level); break; case HFI_PROPERTY_PARAM_VDEC_PIXEL_BITDEPTH: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_bit_depth)) + goto error; + pixel_depth = (struct hfi_bit_depth *)data_ptr; event.bit_depth = pixel_depth->bit_depth; - data_ptr += sizeof(*pixel_depth); + size_read = sizeof(struct hfi_bit_depth); break; case HFI_PROPERTY_PARAM_VDEC_PIC_STRUCT: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_pic_struct)) + goto error; + pic_struct = (struct hfi_pic_struct *)data_ptr; event.pic_struct = pic_struct->progressive_only; - data_ptr += sizeof(*pic_struct); + size_read = sizeof(struct hfi_pic_struct); break; case HFI_PROPERTY_PARAM_VDEC_COLOUR_SPACE: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_colour_space)) + goto error; + colour_info = (struct hfi_colour_space *)data_ptr; event.colour_space = colour_info->colour_space; - data_ptr += sizeof(*colour_info); + size_read = sizeof(struct hfi_colour_space); break; case HFI_PROPERTY_CONFIG_VDEC_ENTROPY: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(u32)) + goto error; + event.entropy_mode = *(u32 *)data_ptr; - data_ptr += sizeof(u32); + size_read = sizeof(u32); break; case HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_buffer_requirements)) + goto error; + bufreq = (struct hfi_buffer_requirements *)data_ptr; event.buf_count = hfi_bufreq_get_count_min(bufreq, ver); - data_ptr += sizeof(*bufreq); + size_read = sizeof(struct hfi_buffer_requirements); break; case HFI_INDEX_EXTRADATA_INPUT_CROP: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_extradata_input_crop)) + goto error; + crop = (struct hfi_extradata_input_crop *)data_ptr; event.input_crop.left = crop->left; event.input_crop.top = crop->top; event.input_crop.width = crop->width; event.input_crop.height = crop->height; - data_ptr += sizeof(*crop); + size_read = sizeof(struct hfi_extradata_input_crop); break; case HFI_PROPERTY_PARAM_VDEC_DPB_COUNTS: - data_ptr += sizeof(u32); + if (rem_bytes < sizeof(struct hfi_dpb_counts)) + goto error; + dpb_count = (struct hfi_dpb_counts *)data_ptr; event.buf_count = dpb_count->fw_min_cnt; - data_ptr += sizeof(*dpb_count); + size_read = sizeof(struct hfi_dpb_counts); break; default: + size_read = 0; break; } + data_ptr += size_read; + rem_bytes -= size_read; num_properties_changed--; } while (num_properties_changed > 0); -done: + inst->ops->event_notify(inst, EVT_SYS_EVENT_CHANGE, &event); + return; + +error: + inst->error = HFI_ERR_SESSION_INSUFFICIENT_RESOURCES; inst->ops->event_notify(inst, EVT_SYS_EVENT_CHANGE, &event); }

2 months, 2 weeks

2
2
0 0

FAILED: patch "[PATCH] mm/ptdump: take the memory hotplug lock inside" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 59305202c67fea50378dcad0cc199dbc13a0e99a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081801-undertake-nuzzle-c4b1@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 59305202c67fea50378dcad0cc199dbc13a0e99a Mon Sep 17 00:00:00 2001 From: Anshuman Khandual <anshuman.khandual(a)arm.com> Date: Fri, 20 Jun 2025 10:54:27 +0530 Subject: [PATCH] mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Dev Jain <dev.jain(a)arm.com> Acked-by: Alexander Gordeev <agordeev(a)linux.ibm.com> [s390] Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c index 68bf1a125502..1e308328c079 100644 --- a/arch/arm64/mm/ptdump_debugfs.c +++ b/arch/arm64/mm/ptdump_debugfs.c @@ -1,6 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 #include <linux/debugfs.h> -#include <linux/memory_hotplug.h> #include <linux/seq_file.h> #include <asm/ptdump.h> @@ -9,9 +8,7 @@ static int ptdump_show(struct seq_file *m, void *v) { struct ptdump_info *info = m->private; - get_online_mems(); ptdump_walk(m, info); - put_online_mems(); return 0; } DEFINE_SHOW_ATTRIBUTE(ptdump); diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c index 32922550a50a..3b51690cc876 100644 --- a/arch/riscv/mm/ptdump.c +++ b/arch/riscv/mm/ptdump.c @@ -6,7 +6,6 @@ #include <linux/efi.h> #include <linux/init.h> #include <linux/debugfs.h> -#include <linux/memory_hotplug.h> #include <linux/seq_file.h> #include <linux/ptdump.h> @@ -413,9 +412,7 @@ bool ptdump_check_wx(void) static int ptdump_show(struct seq_file *m, void *v) { - get_online_mems(); ptdump_walk(m, m->private); - put_online_mems(); return 0; } diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c index ac604b176660..9af2aae0a515 100644 --- a/arch/s390/mm/dump_pagetables.c +++ b/arch/s390/mm/dump_pagetables.c @@ -247,11 +247,9 @@ static int ptdump_show(struct seq_file *m, void *v) .marker = markers, }; - get_online_mems(); mutex_lock(&cpa_mutex); ptdump_walk_pgd(&st.ptdump, &init_mm, NULL); mutex_unlock(&cpa_mutex); - put_online_mems(); return 0; } DEFINE_SHOW_ATTRIBUTE(ptdump); diff --git a/mm/ptdump.c b/mm/ptdump.c index 61a352aa12ed..b600c7f864b8 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -176,6 +176,7 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd) { const struct ptdump_range *range = st->range; + get_online_mems(); mmap_write_lock(mm); while (range->start != range->end) { walk_page_range_debug(mm, range->start, range->end, @@ -183,6 +184,7 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd) range++; } mmap_write_unlock(mm); + put_online_mems(); /* Flush out the last page */ st->note_page_flush(st);

2 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] mm/ptdump: take the memory hotplug lock inside" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 59305202c67fea50378dcad0cc199dbc13a0e99a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081800-autopilot-booted-fb7f@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 59305202c67fea50378dcad0cc199dbc13a0e99a Mon Sep 17 00:00:00 2001 From: Anshuman Khandual <anshuman.khandual(a)arm.com> Date: Fri, 20 Jun 2025 10:54:27 +0530 Subject: [PATCH] mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Dev Jain <dev.jain(a)arm.com> Acked-by: Alexander Gordeev <agordeev(a)linux.ibm.com> [s390] Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c index 68bf1a125502..1e308328c079 100644 --- a/arch/arm64/mm/ptdump_debugfs.c +++ b/arch/arm64/mm/ptdump_debugfs.c @@ -1,6 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 #include <linux/debugfs.h> -#include <linux/memory_hotplug.h> #include <linux/seq_file.h> #include <asm/ptdump.h> @@ -9,9 +8,7 @@ static int ptdump_show(struct seq_file *m, void *v) { struct ptdump_info *info = m->private; - get_online_mems(); ptdump_walk(m, info); - put_online_mems(); return 0; } DEFINE_SHOW_ATTRIBUTE(ptdump); diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c index 32922550a50a..3b51690cc876 100644 --- a/arch/riscv/mm/ptdump.c +++ b/arch/riscv/mm/ptdump.c @@ -6,7 +6,6 @@ #include <linux/efi.h> #include <linux/init.h> #include <linux/debugfs.h> -#include <linux/memory_hotplug.h> #include <linux/seq_file.h> #include <linux/ptdump.h> @@ -413,9 +412,7 @@ bool ptdump_check_wx(void) static int ptdump_show(struct seq_file *m, void *v) { - get_online_mems(); ptdump_walk(m, m->private); - put_online_mems(); return 0; } diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c index ac604b176660..9af2aae0a515 100644 --- a/arch/s390/mm/dump_pagetables.c +++ b/arch/s390/mm/dump_pagetables.c @@ -247,11 +247,9 @@ static int ptdump_show(struct seq_file *m, void *v) .marker = markers, }; - get_online_mems(); mutex_lock(&cpa_mutex); ptdump_walk_pgd(&st.ptdump, &init_mm, NULL); mutex_unlock(&cpa_mutex); - put_online_mems(); return 0; } DEFINE_SHOW_ATTRIBUTE(ptdump); diff --git a/mm/ptdump.c b/mm/ptdump.c index 61a352aa12ed..b600c7f864b8 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -176,6 +176,7 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd) { const struct ptdump_range *range = st->range; + get_online_mems(); mmap_write_lock(mm); while (range->start != range->end) { walk_page_range_debug(mm, range->start, range->end, @@ -183,6 +184,7 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd) range++; } mmap_write_unlock(mm); + put_online_mems(); /* Flush out the last page */ st->note_page_flush(st);

2 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025