- 17 Oct, 2024 22 commits
-
-
Jeongjun Park authored
A report [1] was uploaded from syzbot. In the previous commit 862590ac ("mm: swap: allow cache reclaim to skip slot cache"), the __try_to_reclaim_swap() function reads offset and folio->entry from folio without folio_lock protection. In the currently reported KCSAN log, it is assumed that the actual data-race will not occur because the calltrace that does WRITE already obtains the folio_lock and then writes. However, the existing __try_to_reclaim_swap() function was already implemented to perform reads under folio_lock protection [1], and there is a risk of a data-race occurring through a function other than the one shown in the KCSAN log. Therefore, I think it is appropriate to change read operations for folio to be performed under folio_lock. [1] ================================================================== BUG: KCSAN: data-race in __delete_from_swap_cache / __try_to_reclaim_swap write to 0xffffea0004c90328 of 8 bytes by task 5186 on cpu 0: __delete_from_swap_cache+0x1f0/0x290 mm/swap_state.c:163 delete_from_swap_cache+0x72/0xe0 mm/swap_state.c:243 folio_free_swap+0x1d8/0x1f0 mm/swapfile.c:1850 free_swap_cache mm/swap_state.c:293 [inline] free_pages_and_swap_cache+0x1fc/0x410 mm/swap_state.c:325 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x2cf/0x440 mm/mmu_gather.c:373 zap_pte_range mm/memory.c:1700 [inline] zap_pmd_range mm/memory.c:1739 [inline] zap_pud_range mm/memory.c:1768 [inline] zap_p4d_range mm/memory.c:1789 [inline] unmap_page_range+0x1f3c/0x22d0 mm/memory.c:1810 unmap_single_vma+0x142/0x1d0 mm/memory.c:1856 unmap_vmas+0x18d/0x2b0 mm/memory.c:1900 exit_mmap+0x18a/0x690 mm/mmap.c:1864 __mmput+0x28/0x1b0 kernel/fork.c:1347 mmput+0x4c/0x60 kernel/fork.c:1369 exit_mm+0xe4/0x190 kernel/exit.c:571 do_exit+0x55e/0x17f0 kernel/exit.c:926 do_group_exit+0x102/0x150 kernel/exit.c:1088 get_signal+0xf2a/0x1070 kernel/signal.c:2917 arch_do_signal_or_restart+0x95/0x4b0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x59/0x130 kernel/entry/common.c:218 do_syscall_64+0xd6/0x1c0 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffffea0004c90328 of 8 bytes by task 5189 on cpu 1: __try_to_reclaim_swap+0x9d/0x510 mm/swapfile.c:198 free_swap_and_cache_nr+0x45d/0x8a0 mm/swapfile.c:1915 zap_pte_range mm/memory.c:1656 [inline] zap_pmd_range mm/memory.c:1739 [inline] zap_pud_range mm/memory.c:1768 [inline] zap_p4d_range mm/memory.c:1789 [inline] unmap_page_range+0xcf8/0x22d0 mm/memory.c:1810 unmap_single_vma+0x142/0x1d0 mm/memory.c:1856 unmap_vmas+0x18d/0x2b0 mm/memory.c:1900 exit_mmap+0x18a/0x690 mm/mmap.c:1864 __mmput+0x28/0x1b0 kernel/fork.c:1347 mmput+0x4c/0x60 kernel/fork.c:1369 exit_mm+0xe4/0x190 kernel/exit.c:571 do_exit+0x55e/0x17f0 kernel/exit.c:926 __do_sys_exit kernel/exit.c:1055 [inline] __se_sys_exit kernel/exit.c:1053 [inline] __x64_sys_exit+0x1f/0x20 kernel/exit.c:1053 x64_sys_call+0x2d46/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:61 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x0000000000000242 -> 0x0000000000000000 Link: https://lkml.kernel.org/r/20241007070623.23340-1-aha310510@gmail.com Reported-by: syzbot+fa43f1b63e3aa6f66329@syzkaller.appspotmail.com Fixes: 862590ac ("mm: swap: allow cache reclaim to skip slot cache") Signed-off-by:
Jeongjun Park <aha310510@gmail.com> Acked-by:
Chris Li <chrisl@kernel.org> Reviewed-by:
Kairui Song <kasong@tencent.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Baolin Wang authored
Khugepaged already supports collapsing file large folios (including shmem mTHP) by commit 7de856ff ("mm: khugepaged: support shmem mTHP collapse"), and the control parameters in khugepaged: 'khugepaged_max_ptes_swap' and 'khugepaged_max_ptes_none', still compare based on PTE granularity to determine whether a file collapse is needed. However, the statistics for 'present' and 'swap' in hpage_collapse_scan_file() do not take into account the large folios, which may lead to incorrect judgments regarding the khugepaged_max_ptes_swap/none parameters, resulting in unnecessary file collapses. To fix this issue, take into account the large folios' statistics for 'present' and 'swap' variables in the hpage_collapse_scan_file(). Link: https://lkml.kernel.org/r/c76305d96d12d030a1a346b50503d148364246d2.1728901391.git.baolin.wang@linux.alibaba.com Fixes: 7de856ff ("mm: khugepaged: support shmem mTHP collapse") Signed-off-by:
Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Barry Song <baohua@kernel.org> Reviewed-by:
Zi Yan <ziy@nvidia.com> Reviewed-by:
Yang Shi <shy828301@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by:
-
Andrey Konovalov authored
Add links to the Bugzilla component that's used to track KASAN and KCOV issues. Link: https://lkml.kernel.org/r/20241012225524.117871-1-andrey.konovalov@linux.devSigned-off-by:
Andrey Konovalov <andreyknvl@gmail.com> Acked-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Marco Elver <elver@google.com> Signed-off-by:
-
David Hildenbrand authored
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: 793917d9 ("mm/readahead: Add large folio readahead") Signed-off-by:
Leo Fu <bfu@redhat.com> Tested-by:
Thomas Huth <thuth@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kefeng Wang authored
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@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: 793917d9 ("mm/readahead: Add large folio readahead") Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Ryan Roberts <ryan.roberts@arm.com> Cc: Boqiao Fu <bfu@redhat.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
SeongJae Park authored
DAMON GitHub repos have moved from awslabs GitHub org to damonitor org[1]. Following the change, URLs on documents are also updated[2]. However, commit 2e9b3d6e ("Docs/damon/maintainer-profile: add links in place"), which was added just after the update, was using the deprecated GitHub URLs. Update those to use damonitor GitHub URLs instead. [1] https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org [2] https://lore.kernel.org/20240826015741.80707-2-sj@kernel.org Link: https://lkml.kernel.org/r/20241011170154.70651-3-sj@kernel.org Fixes: 2e9b3d6e ("Docs/damon/maintainer-profile: add links in place") Signed-off-by:
SeongJae Park <sj@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
SeongJae Park authored
Patch series "Docs/damon/maintainer-profile: a couple of minor hotfixes". DAMON maintainer-profile.rst file patches[1] that were merged into the v6.12-rc1 have a couple of minor mistakes. Fix those. [1] https://lore.kernel.org/20240826015741.80707-1-sj@kernel.org This patch (of 2): Links to external web pages on DAMON's maintainer-profile.rst are missing '_' suffixes. As a result, rendered document is having only verbose URLs that cannot be clicked. Fix those. Also, update the link texts for git trees to contain the names of the trees, for better readability and avoiding below Sphinx warning. maintainer-profile.rst:4: WARNING: Duplicate explicit target name: "tree". Link: https://lkml.kernel.org/r/20241011170154.70651-1-sj@kernel.org Link: https://lkml.kernel.org/r/20241011170154.70651-2-sj@kernel.org Fixes: 2e9b3d6e ("Docs/damon/maintainer-profile: add links in place") Signed-off-by:
-
Sidhartha Kumar authored
It is possible for a bulk operation (MA_STATE_BULK is set) to enter the new_end < mt_min_slots[type] case and set wr_rebalance as a store type. This is incorrect as bulk stores do not rebalance per write, but rather after the all of the writes are done through the mas_bulk_rebalance() path. Therefore, add a check to make sure MA_STATE_BULK is not set before we return wr_rebalance as the store type. Also add a test to make sure wr_rebalance is never the store type when doing bulk operations via mas_expected_entries() This is a hotfix for this rc however it has no userspace effects as there are no users of the bulk insertion mode. Link: https://lkml.kernel.org/r/20241011214451.7286-1-sidhartha.kumar@oracle.com Fixes: 5d659bbb ("maple_tree: introduce mas_wr_store_type()") Suggested-by:
Liam Howlett <liam.howlett@oracle.com> Signed-off-by:
Sidhartha <sidhartha.kumar@oracle.com> Reviewed-by:
Wei Yang <richard.weiyang@gmail.com> Reviewed-by:
-
Yang Shi authored
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.com Fixes: 4c9473e8 ("mm/khugepaged: add tracepoint to collapse_file()") Signed-off-by:
Yang Shi <yang@os.amperecomputing.com> Cc: Gautam Menghani <gautammenghani201@gmail.com> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> [6.2+] Signed-off-by:
-
Jinjie Ruan authored
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: b8ee5575 ("mm/damon/sysfs-test: add a unit test for damon_sysfs_set_targets()") Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by:
-
Andy Shevchenko authored
When can_swapin_thp() is unused, it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: mm/memory.c:4184:20: error: unused function 'can_swapin_thp' [-Werror,-Wunused-function] Fix this by removing the unused stub. See also commit 6863f564 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Link: https://lkml.kernel.org/r/20241008191329.2332346-1-andriy.shevchenko@linux.intel.com Fixes: 242d12c9 ("mm: support large folios swap-in for sync io devices") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Andy Chiu authored
Map my outdated addresses within mailmap. Link: https://lkml.kernel.org/r/20241009144934.43027-1-andybnac@gmail.comSigned-off-by:
Andy Chiu <andybnac@gmail.com> Cc: Greentime Hu <greentime.hu@sifive.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Leon Chien <leonchien@synology.com> Signed-off-by:
-
Lorenzo Stoakes authored
Add myself and Liam as co-maintainers of the memory mapping and VMA code alongside Andrew as we are heavily involved in its implementation and maintenance. Link: https://lkml.kernel.org/r/20241009201032.6130-1-lorenzo.stoakes@oracle.comSigned-off-by:
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Acked-by:
-
Brahmajit Das authored
show show_smap_vma_flags() has been a using misspelled initializer in mnemonics[] - it needed to initialize 2 element array of char and it used NUL-padded 2 character string literals (i.e. 3-element initializer). This has been spotted by gcc-15[*]; prior to that gcc quietly dropped the 3rd eleemnt of initializers. To fix this we are increasing the size of mnemonics[] (from mnemonics[BITS_PER_LONG][2] to mnemonics[BITS_PER_LONG][3]) to accomodate the NUL-padded string literals. This also helps us in simplyfying the logic for printing of the flags as instead of printing each character from the mnemonics[], we can just print the mnemonics[] using seq_printf. [*]: fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] 917 | [0 ... (BITS_PER_LONG-1)] = "??", | ^~~~ fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] fs/proc/task_mmu.c:917:49: error: initializer-string for array of `char' is too long [-Werror=unterminate d-string-initialization] ... Stephen pointed out: : The C standard explicitly allows for a string initializer to be too long : due to the NUL byte at the end ... so this warning may be overzealous. but let's make the warning go away anwyay. Link: https://lkml.kernel.org/r/20241005063700.2241027-1-brahmajit.xyz@gmail.com Link: https://lkml.kernel.org/r/20241003093040.47c08382@canb.auug.org.auSigned-off-by:Brahmajit Das <brahmajit.xyz@gmail.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: David Hildenbrand <david@redhat.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Florian Westphal authored
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@linux-foundation.org: add comment] Link: https://lkml.kernel.org/r/20241007205236.11847-1-fw@strlen.de Fixes: a4735739 ("lib: code tagging module support") Signed-off-by:
Florian Westphal <fw@strlen.de> Reported-by:
Ben Greear <greearb@candelatech.com> Closes: https://lore.kernel.org/netdev/bdaaef9d-4364-4171-b82b-bcfc12e207eb@candelatech.com/ Cc: Uladzislau Rezki <urezki@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jann Horn authored
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-5ead9631f2ea@google.com Fixes: 1d65b771 ("mm/khugepaged: retract_page_tables() without mmap or vma lock") Signed-off-by:Jann Horn <jannh@google.com> Signed-off-by:
Qi Zheng <zhengqi.arch@bytedance.com> Reviewed-by:
-
Sebastian Andrzej Siewior authored
Arnd reported a build failure due to the BUILD_BUG_ON() statement in alloc_kmem_cache_cpus(). The test PERCPU_DYNAMIC_EARLY_SIZE < NR_KMALLOC_TYPES * KMALLOC_SHIFT_HIGH * sizeof(struct kmem_cache_cpu) The factors that increase the right side of the equation: - PAGE_SIZE > 4KiB increases KMALLOC_SHIFT_HIGH - For the local_lock_t in kmem_cache_cpu: - PREEMPT_RT adds an actual lock. - LOCKDEP increases the size of the lock. - LOCK_STAT adds additional bytes plus padding to the lockdep structure. The net difference with and without PREEMPT_RT is 88 bytes for the lock_lock_t, 96 bytes for kmem_cache_cpu due to additional padding. This is enough to exceed the 80KiB limit with 16KiB page size - the 8KiB page size is fine. Increase PERCPU_DYNAMIC_SIZE_SHIFT to 13 on configs with PAGE_SIZE larger than 4KiB and LOCKDEP enabled. Link: https://lkml.kernel.org/r/20241007143049.gyMpEu89@linutronix.de Fixes: d8fccd9c ("arm64: Allow to enable PREEMPT_RT.") Signed-off-by:Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410020326.iaZIteIx-lkp@intel.com/Reported-by:
Arnd Bergmann <arnd@kernel.org> Closes: https://lore.kernel.org/20241004095702.637528-1-arnd@kernel.orgAcked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Dennis Zhou <dennis@kernel.org> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Edward Liaw authored
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: cff29458 ("selftests/mm: extend and rename uffd pagemap test") Signed-off-by:
Edward Liaw <edliaw@google.com> Cc: Lokesh Gidra <lokeshgidra@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Edward Liaw authored
Patch series "selftests/mm: fix deadlock after pthread_create". On Android arm, pthread_create followed by a fork caused a deadlock in the case where the fork required work to be completed by the created thread. Update the synchronization primitive to use pthread_barrier instead of atomic_bool. Apply the same fix to the wp-fork-with-event test. This patch (of 2): Swap synchronization primitive with pthread_barrier, so that stdatomic.h does not need to be included. The synchronization is needed on Android ARM64; we see a deadlock with pthread_create when the parent thread races forward before the child has a chance to start doing work. Link: https://lkml.kernel.org/r/20241003211716.371786-1-edliaw@google.com Link: https://lkml.kernel.org/r/20241003211716.371786-2-edliaw@google.com Fixes: cff29458 ("selftests/mm: extend and rename uffd pagemap test") Signed-off-by:
-
OGAWA Hirofumi authored
syszbot produced this with a corrupted fs image. In theory, however an IO error would trigger this also. This affects just an error report, so should not be a serious error. Link: https://lkml.kernel.org/r/87r08wjsnh.fsf@mail.parknet.co.jp Link: https://lkml.kernel.org/r/66ff2c95.050a0220.49194.03e9.GAE@google.comSigned-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by: syzbot+ef0d7bc412553291aa86@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ryusuke Konishi authored
Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. Link: https://lkml.kernel.org/r/20241004033640.6841-1-konishi.ryusuke@gmail.com Fixes: 2ba466d7 ("nilfs2: directory entry operations") Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by:
Lizhi Xu <lizhi.xu@windriver.com> Closes: https://lkml.kernel.org/r/20240927013806.3577931-1-lizhi.xu@windriver.com Reported-by: syzbot+8a192e8d090fa9a31135@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8a192e8d090fa9a31135 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Lorenzo Stoakes authored
Commit f8d112a4 ("mm/mmap: avoid zeroing vma tree in mmap_region()") changed how error handling is performed in mmap_region(). The error value defaults to -ENOMEM, but then gets reassigned immediately to the result of vms_gather_munmap_vmas() if we are performing a MAP_FIXED mapping over existing VMAs (and thus unmapping them). This overwrites the error value, potentially clearing it. After this, we invoke may_expand_vm() and possibly vm_area_alloc(), and check to see if they failed. If they do so, then we perform error-handling logic, but importantly, we do NOT update the error code. This means that, if vms_gather_munmap_vmas() succeeds, but one of these calls does not, the function will return indicating no error, but rather an address value of zero, which is entirely incorrect. Correct this and avoid future confusion by strictly setting error on each and every occasion we jump to the error handling logic, and set the error code immediately prior to doing so. This way we can see at a glance that the error code is always correct. Many thanks to Vegard Nossum who spotted this issue in discussion around this problem. Link: https://lkml.kernel.org/r/20241002073932.13482-1-lorenzo.stoakes@oracle.com Fixes: f8d112a4 ("mm/mmap: avoid zeroing vma tree in mmap_region()") Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Reviewed-by:
-
- 13 Oct, 2024 5 commits
-
-
Linus Torvalds authored
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull smb client fixes from Steve French: "Two fixes for Windows symlink handling" * tag '6.12-rc2-cifs-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: Fix creating native symlinks pointing to current or parent directory cifs: Improve creating native symlinks pointing to directory
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are some small USB fixes for some reported problems for 6.12-rc3. Include in here is: - fix for yurex driver that was caused in -rc1 - build error fix for usbg network filesystem code - onboard_usb_dev build fix - dwc3 driver fixes for reported errors - gadget driver fix - new USB storage driver quirk - xhci resume bugfix All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: net/9p/usbg: Fix build error USB: yurex: kill needless initialization in yurex_read Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant" usb: xhci: Fix problem with xhci resume from suspend usb: misc: onboard_usb_dev: introduce new config symbol for usb5744 SMBus support usb: dwc3: core: Stop processing of pending events if controller is halted usb: dwc3: re-enable runtime PM after failed resume usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip usb: gadget: core: force synchronous registration
-
Linus Torvalds authored
Merge tag 'driver-core-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here is a single driver core fix, and a .mailmap update. The fix is for the rust driver core bindings, turned out that the from_raw binding wasn't a good idea (don't want to pass a pointer to a reference counted object without actually incrementing the pointer.) So this change fixes it up as the from_raw binding came in in -rc1. The other change is a .mailmap update. Both have been in linux-next for a while with no reported issues" * tag 'driver-core-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: mailmap: update mail for Fiona Behrens rust: device: change the from_raw() function
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fix from Michael Ellerman: - Fix crash in memcpy on 8xx due to dcbz workaround since recent changes Thanks to Christophe Leroy. * tag 'powerpc-6.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/8xx: Fix kernel DTLB miss on dcbz
-
- 12 Oct, 2024 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Four small fixes, three in drivers and one in the FC transport class to add idempotence to state setting" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: scsi_transport_fc: Allow setting rport state to current state scsi: wd33c93: Don't use stale scsi_pointer value scsi: fnic: Move flush_work initialization out of if block scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()
-
Linus Torvalds authored
Merge tag 'hwmon-for-v6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Add missing dependencies on REGMAP_I2C for several drivers - Fix memory leak in adt7475 driver - Relabel Columbiaville temperature sensor in intel-m10-bmc-hwmon driver to match other sensor labels * tag 'hwmon-for-v6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (max1668) Add missing dependency on REGMAP_I2C hwmon: (ltc2991) Add missing dependency on REGMAP_I2C hwmon: (adt7470) Add missing dependency on REGMAP_I2C hwmon: (adm9240) Add missing dependency on REGMAP_I2C hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C hwmon: (tmp513) Add missing dependency on REGMAP_I2C hwmon: (adt7475) Fix memory leak in adt7475_fan_pwm_config() hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature
-
- 11 Oct, 2024 11 commits
-
-
Linus Torvalds authored
Merge tag 'linux_kselftest-fixes-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fixes from Shuah Khan: "Fixes for build, run-time errors, and reporting errors: - ftrace: regression test for a kernel crash when running function graph tracing and then enabling function profiler. - rseq: fix for mm_cid test failure. - vDSO: - fixes to reporting skip and other error conditions - changes unconditionally build chacha and getrandom tests on all architectures to make it easier for them to run in CIs - build error when sched.h to bring in CLONE_NEWTIME define" * tag 'linux_kselftest-fixes-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: ftrace/selftest: Test combination of function_graph tracer and function profiler selftests/rseq: Fix mm_cid test failure selftests: vDSO: Explicitly include sched.h selftests: vDSO: improve getrandom and chacha error messages selftests: vDSO: unconditionally build getrandom test selftests: vDSO: unconditionally build chacha test
-
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linuxLinus Torvalds authored
Pull devicetree fixes from Rob Herring: - Disable kunit tests for arm64+ACPI - Fix refcount issue in kunit tests - Drop constraints on non-conformant 'interrupt-map' in fsl,ls-extirq - Drop type ref on 'msi-parent in fsl,qoriq-mc binding - Move elgin,jg10309-01 to its own binding from trivial-devices * tag 'devicetree-fixes-for-6.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of: Skip kunit tests when arm64+ACPI doesn't populate root node of: Fix unbalanced of node refcount and memory leaks dt-bindings: interrupt-controller: fsl,ls-extirq: workaround wrong interrupt-map number dt-bindings: misc: fsl,qoriq-mc: remove ref for msi-parent dt-bindings: display: elgin,jg10309-01: Add own binding
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdevLinus Torvalds authored
Pull fbdev platform driver fix from Helge Deller: "Switch fbdev drivers back to struct platform_driver::remove() Now that 'remove()' has been converted to the sane new API, there's no reason for the 'remove_new()' use, so this converts back to the traditional and simpler name. See commits 5c5a7680 ("platform: Provide a remove callback that returns no value") 0edb555a ("platform: Make platform_driver::remove() return void") for background to this all" * tag 'fbdev-for-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: Switch back to struct platform_driver::remove() -
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linuxLinus Torvalds authored
Pull gpio fixes from Bartosz Golaszewski: - fix clock handle leak in probe() error path in gpio-aspeed - add a dummy register read to ensure the write actually completed * tag 'gpio-fixes-for-v6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: aspeed: Use devm_clk api to manage clock source gpio: aspeed: Add the flush write to ensure the write complete.
-
git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds authored
Pull NFS client fixes from Anna Schumaker: "Localio Bugfixes: - remove duplicated include in localio.c - fix race in NFS calls to nfsd_file_put_local() and nfsd_serv_put() - fix Kconfig for NFS_COMMON_LOCALIO_SUPPORT - fix nfsd_file tracepoints to handle NULL rqstp pointers Other Bugfixes: - fix program selection loop in svc_process_common - fix integer overflow in decode_rc_list() - prevent NULL-pointer dereference in nfs42_complete_copies() - fix CB_RECALL performance issues when using a large number of delegations" * tag 'nfs-for-6.12-2' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: remove revoked delegation from server's delegation list nfsd/localio: fix nfsd_file tracepoints to handle NULL rqstp nfs_common: fix Kconfig for NFS_COMMON_LOCALIO_SUPPORT nfs_common: fix race in NFS calls to nfsd_file_put_local() and nfsd_serv_put() NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() SUNRPC: Fix integer overflow in decode_rc_list() sunrpc: fix prog selection loop in svc_process_common nfs: Remove duplicated include in localio.c -
git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linuxLinus Torvalds authored
Pull RCU fix from Neeraj Upadhyay: "Fix rcuog kthread wakeup invocation from softirq context on a CPU which has been marked offline. This can happen when new callbacks are enqueued from a softirq on an offline CPU before it calls rcutree_report_cpu_dead(). When this happens on NOCB configuration, the rcuog wake-up is deferred through an IPI to an online CPU. This is done to avoid call into the scheduler which can risk arming the RT-bandwidth after hrtimers have been migrated out and disabled. However, doing IPI call from softirq is not allowed: Fix this by forcing deferred rcuog wakeup through the NOCB timer when the CPU is offline" * tag 'rcu.fixes.6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: rcu/nocb: Fix rcuog wake-up from offline softirq
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull xen fix from Juergen Gross: "A fix for topology information of Xen PV guests" * tag 'for-linus-6.12a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE
-
Steven Rostedt authored
Masami reported a bug when running function graph tracing then the function profiler. The following commands would cause a kernel crash: # cd /sys/kernel/tracing/ # echo function_graph > current_tracer # echo 1 > function_profile_enabled In that order. Create a test to test this two to make sure this does not come back as a regression. Link: https://lore.kernel.org/172398528350.293426.8347220120333730248.stgit@devnote2 Link: https://lore.kernel.org/all/20241010165235.35122877@gandalf.local.home/Acked-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org>
-
Mathieu Desnoyers authored
Adapt the rseq.c/rseq.h code to follow GNU C library changes introduced by: glibc commit 2e456ccf0c34 ("Linux: Make __rseq_size useful for feature detection (bug 31965)") Without this fix, rseq selftests for mm_cid fail: ./run_param_test.sh Default parameters Running test spinlock Running compare-twice test spinlock Running mm_cid test spinlock Error: cpu id getter unavailable Fixes: 18c23558 ("selftests/rseq: Implement rseq mm_cid field support") Signed-off-by:Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra <peterz@infradead.org> CC: Boqun Feng <boqun.feng@gmail.com> CC: "Paul E. McKenney" <paulmck@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> CC: Carlos O'Donell <carlos@redhat.com> CC: Florian Weimer <fweimer@redhat.com> CC: linux-kselftest@vger.kernel.org CC: stable@vger.kernel.org Signed-off-by:
-
git://git.kernel.dk/linuxLinus Torvalds authored
Pull io_uring fixes from Jens Axboe: - Explicitly have a mshot_finished condition for IORING_OP_RECV in multishot mode, similarly to what IORING_OP_RECVMSG has. This doesn't fix a bug right now, but it makes it harder to actually have a bug here if a request takes multiple iterations to finish. - Fix handling of retry of read/write of !FMODE_NOWAIT files. If they are pollable, that's all we need. * tag 'io_uring-6.12-20241011' of git://git.kernel.dk/linux: io_uring/rw: allow pollable non-blocking attempts for !FMODE_NOWAIT io_uring/rw: fix cflags posting for single issue multishot read
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fixes from Rafael Wysocki: "These address two issues in the TPMI module of the Intel RAPL power capping driver and one issue in the processor part of the Intel int340x thermal driver, update a CPU ID list and register definitions needed for RAPL PL4 support and remove some unused code. Specifics: - Fix the TPMI_RAPL_REG_DOMAIN_INFO register offset in the TPMI part of the Intel RAPL power capping driver, make it ignore minor hardware version mismatches (which only indicate exposing additional features) and update register definitions in it to enable PL4 support (Zhang Rui) - Add Arrow Lake-U to the list of processors supporting PL4 in the MSR part of the Intel RAPL power capping driver (Sumeet Pawnikar) - Remove excess pci_disable_device() calls from the processor part of the int340x thermal driver to address a warning triggered during module unload and remove unused CPU hotplug code related to RAPL support from it (Zhang Rui)" * tag 'pm-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: intel: int340x: processor: Add MMIO RAPL PL4 support thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U powercap: intel_rapl_tpmi: Ignore minor version change thermal: intel: int340x: processor: Fix warning during module unload powercap: intel_rapl_tpmi: Fix bogus register reading
-
