October 2024 - Linux-stable-mirror

[PATCH v2 1/2] wifi: ath12k: fix crash when unbinding

by Jose Ignacio Tornos Martinez

If there is an error during some initialization realated to firmware, the funcion ath12k_dp_cc_cleanup is already call to release resources. However this is released again when the device is unbinded (ath12k_pci), and we get: [ 382.050650] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 382.050656] #PF: supervisor read access in kernel mode [ 382.050657] #PF: error_code(0x0000) - not-present page [ 382.050659] PGD 0 P4D 0 [ 382.050661] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 382.050664] CPU: 0 UID: 0 PID: 6541 Comm: bash Kdump: loaded Not tainted 6.12.0-rc1+ #14 [ 382.050666] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 382.050667] RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] [ 382.050688] Code: 8b 76 28 48 8b 7b 10 45 31 c0 b9 02 00 00 00 e8 30 3d 35 c2 be 02 00 00 00 4c 89 f7 e8 e3 00 fb c2 49 83 c7 28 49 39 ef 74 31 <41> f6 47 20 01 75 ab 4c 89 ff e8 2b de a2 c2 84 c0 74 0e 49 8b 17 [ 382.050689] RSP: 0018:ffffa3e3c0e83990 EFLAGS: 00010297 [ 382.050691] RAX: 0000000000000000 RBX: ffff90de08750000 RCX: 0000000000000000 [ 382.050692] RDX: 0000000000000001 RSI: ffff90de08751178 RDI: ffff90de08751970 [ 382.050693] RBP: 0000000000005000 R08: 0000000000000200 R09: 000000000040003f [ 382.050694] R10: 000000000040003f R11: 0000000000000000 R12: dead000000000122 [ 382.050695] R13: dead000000000100 R14: ffffffffc0b6f948 R15: 0000000000000000 [ 382.050696] FS: 00007f216b1ab740(0000) GS:ffff90de5fc00000(0000) knlGS:0000000000000000 [ 382.050698] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 382.050699] CR2: 0000000000000020 CR3: 000000001a26c000 CR4: 0000000000752ef0 [ 382.050702] PKRU: 55555554 [ 382.050703] Call Trace: [ 382.050705] <TASK> [ 382.050707] ? __die_body.cold+0x19/0x27 [ 382.050719] ? page_fault_oops+0x15a/0x2f0 [ 382.050723] ? exc_page_fault+0x7e/0x180 [ 382.050724] ? asm_exc_page_fault+0x26/0x30 [ 382.050729] ? ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] [ 382.050740] ? delay_halt_tpause+0x1a/0x20 [ 382.050742] ath12k_dp_free+0x67/0x110 [ath12k] [ 382.050753] ath12k_core_deinit+0x8d/0xb0 [ath12k] [ 382.050762] ath12k_pci_remove+0x50/0xf0 [ath12k] [ 382.050771] pci_device_remove+0x3f/0xb0 [ 382.050773] device_release_driver_internal+0x19c/0x200 [ 382.050777] unbind_store+0xa1/0xb0 ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set to NULL the relaeased structure in ath12k_dp_cc_cleanup at the end. cc: stable(a)vger.kernel.org Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> --- v2: - Fix the commit size in Fixes v1: https://lore.kernel.org/linux-wireless/20241010175102.207324-2-jtornosm@red… drivers/net/wireless/ath/ath12k/dp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath12k/dp.c b/drivers/net/wireless/ath/ath12k/dp.c index 61aa78d8bd8c..789d430e4455 100644 --- a/drivers/net/wireless/ath/ath12k/dp.c +++ b/drivers/net/wireless/ath/ath12k/dp.c @@ -1241,6 +1241,7 @@ static void ath12k_dp_cc_cleanup(struct ath12k_base *ab) } kfree(dp->spt_info); + dp->spt_info = NULL; } static void ath12k_dp_reoq_lut_cleanup(struct ath12k_base *ab) -- 2.46.2

8 months, 2 weeks

2
2
0 0

[merged mm-hotfixes-stable] mm-mglru-only-clear-kswapd_failures-if-reclaimable.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/mglru: only clear kswapd_failures if reclaimable has been removed from the -mm tree. Its filename was mm-mglru-only-clear-kswapd_failures-if-reclaimable.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: Wei Xu <weixugc(a)google.com> Subject: mm/mglru: only clear kswapd_failures if reclaimable Date: Mon, 14 Oct 2024 22:12:11 +0000 lru_gen_shrink_node() unconditionally clears kswapd_failures, which can prevent kswapd from sleeping and cause 100% kswapd cpu usage even when kswapd repeatedly fails to make progress in reclaim. Only clear kswap_failures in lru_gen_shrink_node() if reclaim makes some progress, similar to shrink_node(). I happened to run into this problem in one of my tests recently. It requires a combination of several conditions: The allocator needs to allocate a right amount of pages such that it can wake up kswapd without itself being OOM killed; there is no memory for kswapd to reclaim (My test disables swap and cleans page cache first); no other process frees enough memory at the same time. Link: https://lkml.kernel.org/r/20241014221211.832591-1-weixugc@google.com Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Wei Xu <weixugc(a)google.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Brian Geffon <bgeffon(a)google.com> Cc: Jan Alexander Steffens <heftig(a)archlinux.org> Cc: Suleiman Souhlal <suleiman(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmscan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/vmscan.c~mm-mglru-only-clear-kswapd_failures-if-reclaimable +++ a/mm/vmscan.c @@ -4963,8 +4963,8 @@ static void lru_gen_shrink_node(struct p blk_finish_plug(&plug); done: - /* kswapd should never fail */ - pgdat->kswapd_failures = 0; + if (sc->nr_reclaimed > reclaimed) + pgdat->kswapd_failures = 0; } /****************************************************************************** _ Patches currently in -mm which might be from weixugc(a)google.com are

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-swapfile-skip-hugetlb-pages-for-unuse_vma.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/swapfile: skip HugeTLB pages for unuse_vma has been removed from the -mm tree. Its filename was mm-swapfile-skip-hugetlb-pages-for-unuse_vma.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: Liu Shixin <liushixin2(a)huawei.com> Subject: mm/swapfile: skip HugeTLB pages for unuse_vma Date: Tue, 15 Oct 2024 09:45:21 +0800 I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Link: https://lkml.kernel.org/r/20241015014521.570237-1-liushixin2@huawei.com Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/swapfile.c~mm-swapfile-skip-hugetlb-pages-for-unuse_vma +++ a/mm/swapfile.c @@ -2313,7 +2313,7 @@ static int unuse_mm(struct mm_struct *mm mmap_read_lock(mm); for_each_vma(vmi, vma) { - if (vma->anon_vma) { + if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type); if (ret) break; _ Patches currently in -mm which might be from liushixin2(a)huawei.com are

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-dont-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: don't install PMD mappings when THPs are disabled by the hw/process/vma has been removed from the -mm tree. Its filename was mm-dont-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.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: David Hildenbrand <david(a)redhat.com> Subject: mm: don't install PMD mappings when THPs are disabled by the hw/process/vma Date: Fri, 11 Oct 2024 12:24:45 +0200 We (or rather, readahead logic :) ) might be allocating a THP in the pagecache and then try mapping it into a process that explicitly disabled THP: we might end up installing PMD mappings. This is a problem for s390x KVM, which explicitly remaps all PMD-mapped THPs to be PTE-mapped in s390_enable_sie()->thp_split_mm(), before starting the VM. For example, starting a VM backed on a file system with large folios supported makes the VM crash when the VM tries accessing such a mapping using KVM. Is it also a problem when the HW disabled THP using TRANSPARENT_HUGEPAGE_UNSUPPORTED? At least on x86 this would be the case without X86_FEATURE_PSE. In the future, we might be able to do better on s390x and only disallow PMD mappings -- what s390x and likely TRANSPARENT_HUGEPAGE_UNSUPPORTED really wants. For now, fix it by essentially performing the same check as would be done in __thp_vma_allowable_orders() or in shmem code, where this works as expected, and disallow PMD mappings, making us fallback to PTE mappings. Link: https://lkml.kernel.org/r/20241011102445.934409-3-david@redhat.com Fixes: 793917d997df ("mm/readahead: Add large folio readahead") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Leo Fu <bfu(a)redhat.com> Tested-by: Thomas Huth <thuth(a)redhat.com> Cc: Thomas Huth <thuth(a)redhat.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Janosch Frank <frankja(a)linux.ibm.com> Cc: Claudio Imbrenda <imbrenda(a)linux.ibm.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/mm/memory.c~mm-dont-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma +++ a/mm/memory.c @@ -4920,6 +4920,15 @@ vm_fault_t do_set_pmd(struct vm_fault *v pmd_t entry; vm_fault_t ret = VM_FAULT_FALLBACK; + /* + * It is too late to allocate a small folio, we already have a large + * folio in the pagecache: especially s390 KVM cannot tolerate any + * PMD mappings, but PTE-mapped THP are fine. So let's simply refuse any + * PMD mappings if THPs are disabled. + */ + if (thp_disabled_by_hw() || vma_thp_disabled(vma, vma->vm_flags)) + return ret; + if (!thp_vma_suitable_order(vma, haddr, PMD_ORDER)) return ret; _ Patches currently in -mm which might be from david(a)redhat.com are mm-pagewalk-fix-usage-of-pmd_leaf-pud_leaf-without-present-check.patch selftests-mm-hugetlb_fault_after_madv-use-default-hguetlb-page-size.patch selftests-mm-hugetlb_fault_after_madv-improve-test-output.patch

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw() has been removed from the -mm tree. Its filename was mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.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: Kefeng Wang <wangkefeng.wang(a)huawei.com> Subject: mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw() Date: Fri, 11 Oct 2024 12:24:44 +0200 Patch series "mm: don't install PMD mappings when THPs are disabled by the hw/process/vma". During testing, it was found that we can get PMD mappings in processes where THP (and more precisely, PMD mappings) are supposed to be disabled. While it works as expected for anon+shmem, the pagecache is the problematic bit. For s390 KVM this currently means that a VM backed by a file located on filesystem with large folio support can crash when KVM tries accessing the problematic page, because the readahead logic might decide to use a PMD-sized THP and faulting it into the page tables will install a PMD mapping, something that s390 KVM cannot tolerate. This might also be a problem with HW that does not support PMD mappings, but I did not try reproducing it. Fix it by respecting the ways to disable THPs when deciding whether we can install a PMD mapping. khugepaged should already be taking care of not collapsing if THPs are effectively disabled for the hw/process/vma. This patch (of 2): Add vma_thp_disabled() and thp_disabled_by_hw() helpers to be shared by shmem_allowable_huge_orders() and __thp_vma_allowable_orders(). [david(a)redhat.com: rename to vma_thp_disabled(), split out thp_disabled_by_hw() ] Link: https://lkml.kernel.org/r/20241011102445.934409-2-david@redhat.com Fixes: 793917d997df ("mm/readahead: Add large folio readahead") Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Leo Fu <bfu(a)redhat.com> Tested-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Boqiao Fu <bfu(a)redhat.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Claudio Imbrenda <imbrenda(a)linux.ibm.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Janosch Frank <frankja(a)linux.ibm.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/huge_mm.h | 18 ++++++++++++++++++ mm/huge_memory.c | 13 +------------ mm/shmem.c | 7 +------ 3 files changed, 20 insertions(+), 18 deletions(-) --- a/include/linux/huge_mm.h~mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw +++ a/include/linux/huge_mm.h @@ -322,6 +322,24 @@ struct thpsize { (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG)) +static inline bool vma_thp_disabled(struct vm_area_struct *vma, + unsigned long vm_flags) +{ + /* + * Explicitly disabled through madvise or prctl, or some + * architectures may disable THP for some mappings, for + * example, s390 kvm. + */ + return (vm_flags & VM_NOHUGEPAGE) || + test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags); +} + +static inline bool thp_disabled_by_hw(void) +{ + /* If the hardware/firmware marked hugepage support disabled. */ + return transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED); +} + unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); unsigned long thp_get_unmapped_area_vmflags(struct file *filp, unsigned long addr, --- a/mm/huge_memory.c~mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw +++ a/mm/huge_memory.c @@ -109,18 +109,7 @@ unsigned long __thp_vma_allowable_orders if (!vma->vm_mm) /* vdso */ return 0; - /* - * Explicitly disabled through madvise or prctl, or some - * architectures may disable THP for some mappings, for - * example, s390 kvm. - * */ - if ((vm_flags & VM_NOHUGEPAGE) || - test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags)) - return 0; - /* - * If the hardware/firmware marked hugepage support disabled. - */ - if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED)) + if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags)) return 0; /* khugepaged doesn't collapse DAX vma, but page fault is fine. */ --- a/mm/shmem.c~mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw +++ a/mm/shmem.c @@ -1664,12 +1664,7 @@ unsigned long shmem_allowable_huge_order loff_t i_size; int order; - if (vma && ((vm_flags & VM_NOHUGEPAGE) || - test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))) - return 0; - - /* If the hardware/firmware marked hugepage support disabled. */ - if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED)) + if (thp_disabled_by_hw() || (vma && vma_thp_disabled(vma, vm_flags))) return 0; global_huge = shmem_huge_global_enabled(inode, index, write_end, _ Patches currently in -mm which might be from wangkefeng.wang(a)huawei.com are mm-remove-unused-hugepage-for-vma_alloc_folio.patch

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-khugepaged-fix-the-arguments-order-in-khugepaged_collapse_file-trace-point.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace point has been removed from the -mm tree. Its filename was mm-khugepaged-fix-the-arguments-order-in-khugepaged_collapse_file-trace-point.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: Yang Shi <yang(a)os.amperecomputing.com> Subject: mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace point Date: Fri, 11 Oct 2024 18:17:02 -0700 The "addr" and "is_shmem" arguments have different order in TP_PROTO and TP_ARGS. This resulted in the incorrect trace result: text-hugepage-644429 [276] 392092.878683: mm_khugepaged_collapse_file: mm=0xffff20025d52c440, hpage_pfn=0x200678c00, index=512, addr=1, is_shmem=0, filename=text-hugepage, nr=512, result=failed The value of "addr" is wrong because it was treated as bool value, the type of is_shmem. Fix the order in TP_PROTO to keep "addr" is before "is_shmem" since the original patch review suggested this order to achieve best packing. And use "lx" for "addr" instead of "ld" in TP_printk because address is typically shown in hex. After the fix, the trace result looks correct: text-hugepage-7291 [004] 128.627251: mm_khugepaged_collapse_file: mm=0xffff0001328f9500, hpage_pfn=0x20016ea00, index=512, addr=0x400000, is_shmem=0, filename=text-hugepage, nr=512, result=failed Link: https://lkml.kernel.org/r/20241012011702.1084846-1-yang@os.amperecomputing.… Fixes: 4c9473e87e75 ("mm/khugepaged: add tracepoint to collapse_file()") Signed-off-by: Yang Shi <yang(a)os.amperecomputing.com> Cc: Gautam Menghani <gautammenghani201(a)gmail.com> Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: <stable(a)vger.kernel.org> [6.2+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/trace/events/huge_memory.h | 4 ++-- mm/khugepaged.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) --- a/include/trace/events/huge_memory.h~mm-khugepaged-fix-the-arguments-order-in-khugepaged_collapse_file-trace-point +++ a/include/trace/events/huge_memory.h @@ -208,7 +208,7 @@ TRACE_EVENT(mm_khugepaged_scan_file, TRACE_EVENT(mm_khugepaged_collapse_file, TP_PROTO(struct mm_struct *mm, struct folio *new_folio, pgoff_t index, - bool is_shmem, unsigned long addr, struct file *file, + unsigned long addr, bool is_shmem, struct file *file, int nr, int result), TP_ARGS(mm, new_folio, index, addr, is_shmem, file, nr, result), TP_STRUCT__entry( @@ -233,7 +233,7 @@ TRACE_EVENT(mm_khugepaged_collapse_file, __entry->result = result; ), - TP_printk("mm=%p, hpage_pfn=0x%lx, index=%ld, addr=%ld, is_shmem=%d, filename=%s, nr=%d, result=%s", + TP_printk("mm=%p, hpage_pfn=0x%lx, index=%ld, addr=%lx, is_shmem=%d, filename=%s, nr=%d, result=%s", __entry->mm, __entry->hpfn, __entry->index, --- a/mm/khugepaged.c~mm-khugepaged-fix-the-arguments-order-in-khugepaged_collapse_file-trace-point +++ a/mm/khugepaged.c @@ -2227,7 +2227,7 @@ rollback: folio_put(new_folio); out: VM_BUG_ON(!list_empty(&pagelist)); - trace_mm_khugepaged_collapse_file(mm, new_folio, index, is_shmem, addr, file, HPAGE_PMD_NR, result); + trace_mm_khugepaged_collapse_file(mm, new_folio, index, addr, is_shmem, file, HPAGE_PMD_NR, result); return result; } _ Patches currently in -mm which might be from yang(a)os.amperecomputing.com are

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-fix-memory-leak-in-damon_sysfs_test_add_targets.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() has been removed from the -mm tree. Its filename was mm-damon-fix-memory-leak-in-damon_sysfs_test_add_targets.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: Jinjie Ruan <ruanjinjie(a)huawei.com> Subject: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() Date: Thu, 10 Oct 2024 20:53:23 +0800 The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. unreferenced object 0xffffff80c2a8db80 (size 96): comm "kunit_try_catch", pid 187, jiffies 4294894363 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 Link: https://lkml.kernel.org/r/20241010125323.3127187-1-ruanjinjie@huawei.com Fixes: b8ee5575f763 ("mm/damon/sysfs-test: add a unit test for damon_sysfs_set_targets()") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.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/tests/sysfs-kunit.h | 1 + 1 file changed, 1 insertion(+) --- a/mm/damon/tests/sysfs-kunit.h~mm-damon-fix-memory-leak-in-damon_sysfs_test_add_targets +++ a/mm/damon/tests/sysfs-kunit.h @@ -67,6 +67,7 @@ static void damon_sysfs_test_add_targets damon_destroy_ctx(ctx); kfree(sysfs_targets->targets_arr); kfree(sysfs_targets); + kfree(sysfs_target->regions); kfree(sysfs_target); } _ Patches currently in -mm which might be from ruanjinjie(a)huawei.com are

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] lib-alloc_tag_module_unload-must-wait-for-pending-kfree_rcu-calls.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls has been removed from the -mm tree. Its filename was lib-alloc_tag_module_unload-must-wait-for-pending-kfree_rcu-calls.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: Florian Westphal <fw(a)strlen.de> Subject: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Date: Mon, 7 Oct 2024 22:52:24 +0200 Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm(a)linux-foundation.org: add comment] Link: https://lkml.kernel.org/r/20241007205236.11847-1-fw@strlen.de Fixes: a473573964e5 ("lib: code tagging module support") Signed-off-by: Florian Westphal <fw(a)strlen.de> Reported-by: Ben Greear <greearb(a)candelatech.com> Closes: https://lore.kernel.org/netdev/bdaaef9d-4364-4171-b82b-bcfc12e207eb@candela… Cc: Uladzislau Rezki <urezki(a)gmail.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/codetag.c | 3 +++ 1 file changed, 3 insertions(+) --- a/lib/codetag.c~lib-alloc_tag_module_unload-must-wait-for-pending-kfree_rcu-calls +++ a/lib/codetag.c @@ -228,6 +228,9 @@ bool codetag_unload_module(struct module if (!mod) return true; + /* await any module's kfree_rcu() operations to complete */ + kvfree_rcu_barrier(); + mutex_lock(&codetag_lock); list_for_each_entry(cttype, &codetag_types, link) { struct codetag_module *found = NULL; _ Patches currently in -mm which might be from fw(a)strlen.de are

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-mremap-fix-move_normal_pmd-retract_page_tables-race.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/mremap: fix move_normal_pmd/retract_page_tables race has been removed from the -mm tree. Its filename was mm-mremap-fix-move_normal_pmd-retract_page_tables-race.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: Jann Horn <jannh(a)google.com> Subject: mm/mremap: fix move_normal_pmd/retract_page_tables race Date: Mon, 07 Oct 2024 23:42:04 +0200 In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable. Link: https://lkml.kernel.org/r/20241007-move_normal_pmd-vs-collapse-fix-2-v1-1-5… Fixes: 1d65b771bc08 ("mm/khugepaged: retract_page_tables() without mmap or vma lock") Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Co-developed-by: David Hildenbrand <david(a)redhat.com> Closes: https://project-zero.issues.chromium.org/371047675 Acked-by: Qi Zheng <zhengqi.arch(a)bytedance.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Joel Fernandes <joel(a)joelfernandes.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mremap.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/mm/mremap.c~mm-mremap-fix-move_normal_pmd-retract_page_tables-race +++ a/mm/mremap.c @@ -238,6 +238,7 @@ static bool move_normal_pmd(struct vm_ar { spinlock_t *old_ptl, *new_ptl; struct mm_struct *mm = vma->vm_mm; + bool res = false; pmd_t pmd; if (!arch_supports_page_table_move()) @@ -277,19 +278,25 @@ static bool move_normal_pmd(struct vm_ar if (new_ptl != old_ptl) spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING); - /* Clear the pmd */ pmd = *old_pmd; + + /* Racing with collapse? */ + if (unlikely(!pmd_present(pmd) || pmd_leaf(pmd))) + goto out_unlock; + /* Clear the pmd */ pmd_clear(old_pmd); + res = true; VM_BUG_ON(!pmd_none(*new_pmd)); pmd_populate(mm, new_pmd, pmd_pgtable(pmd)); flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE); +out_unlock: if (new_ptl != old_ptl) spin_unlock(new_ptl); spin_unlock(old_ptl); - return true; + return res; } #else static inline bool move_normal_pmd(struct vm_area_struct *vma, _ Patches currently in -mm which might be from jannh(a)google.com are mm-mark-mas-allocation-in-vms_abort_munmap_vmas-as-__gfp_nofail.patch

8 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] selftests-mm-fix-deadlock-for-fork-after-pthread_create-on-arm.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: fix deadlock for fork after pthread_create on ARM has been removed from the -mm tree. Its filename was selftests-mm-fix-deadlock-for-fork-after-pthread_create-on-arm.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: Edward Liaw <edliaw(a)google.com> Subject: selftests/mm: fix deadlock for fork after pthread_create on ARM Date: Thu, 3 Oct 2024 21:17:11 +0000 On Android with arm, there is some synchronization needed to avoid a deadlock when forking after pthread_create. Link: https://lkml.kernel.org/r/20241003211716.371786-3-edliaw@google.com Fixes: cff294582798 ("selftests/mm: extend and rename uffd pagemap test") Signed-off-by: Edward Liaw <edliaw(a)google.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/uffd-unit-tests.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/tools/testing/selftests/mm/uffd-unit-tests.c~selftests-mm-fix-deadlock-for-fork-after-pthread_create-on-arm +++ a/tools/testing/selftests/mm/uffd-unit-tests.c @@ -241,6 +241,9 @@ static void *fork_event_consumer(void *d fork_event_args *args = data; struct uffd_msg msg = { 0 }; + /* Ready for parent thread to fork */ + pthread_barrier_wait(&ready_for_fork); + /* Read until a full msg received */ while (uffd_read_msg(args->parent_uffd, &msg)); @@ -308,8 +311,12 @@ static int pagemap_test_fork(int uffd, b /* Prepare a thread to resolve EVENT_FORK */ if (with_event) { + pthread_barrier_init(&ready_for_fork, NULL, 2); if (pthread_create(&thread, NULL, fork_event_consumer, &args)) err("pthread_create()"); + /* Wait for child thread to start before forking */ + pthread_barrier_wait(&ready_for_fork); + pthread_barrier_destroy(&ready_for_fork); } child = fork(); _ Patches currently in -mm which might be from edliaw(a)google.com are

8 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024