March 2024 - Linux-stable-mirror

+ mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/secretmem: fix GUP-fast succeeding on secretmem folios has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.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: David Hildenbrand <david(a)redhat.com> Subject: mm/secretmem: fix GUP-fast succeeding on secretmem folios Date: Tue, 26 Mar 2024 15:32:08 +0100 folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Link: https://lkml.kernel.org/r/20240326143210.291116-2-david@redhat.com Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/secretmem.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/secretmem.h~mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios +++ a/include/linux/secretmem.h @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(st /* * Using folio_mapping() is quite slow because of the actual call * instruction. - * We know that secretmem pages are not compound and LRU so we can + * We know that secretmem pages are not compound, so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio)) return false; mapping = (struct address_space *) _ Patches currently in -mm which might be from david(a)redhat.com are mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch mm-madvise-make-madv_populate_readwrite-handle-vm_fault_retry-properly.patch mm-madvise-dont-perform-madvise-vma-walk-for-madv_populate_readwrite.patch mm-userfaultfd-dont-place-zeropages-when-zeropages-are-disallowed.patch s390-mm-re-enable-the-shared-zeropage-for-pv-and-skeys-kvm-guests.patch mm-convert-folio_estimated_sharers-to-folio_likely_mapped_shared.patch mm-convert-folio_estimated_sharers-to-folio_likely_mapped_shared-fix.patch selftests-memfd_secret-add-vmsplice-test.patch mm-merge-folio_is_secretmem-into-folio_fast_pin_allowed.patch

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/secretmem: fix GUP-fast succeeding on secretmem folios has been removed from the -mm tree. Its filename was mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.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/secretmem: fix GUP-fast succeeding on secretmem folios Date: Mon, 25 Mar 2024 14:41:12 +0100 folio_is_secretmem() states that secretmem folios cannot be LRU folios: so we may only exit early if we find an LRU folio. Yet, we exit early if we find a folio that is not a secretmem folio. Consequently, folio_is_secretmem() fails to detect secretmem folios and, therefore, we can succeed in grabbing a secretmem folio during GUP-fast, crashing the kernel when we later try reading/writing to the folio, because the folio has been unmapped from the directmap. Link: https://lkml.kernel.org/r/20240325134114.257544-2-david@redhat.com Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: "Mike Rapoport (IBM)" <rppt(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/secretmem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/secretmem.h~mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios +++ a/include/linux/secretmem.h @@ -16,7 +16,7 @@ static inline bool folio_is_secretmem(st * We know that secretmem pages are not compound and LRU so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio) || folio_test_lru(folio)) return false; mapping = (struct address_space *) _ Patches currently in -mm which might be from david(a)redhat.com are mm-madvise-make-madv_populate_readwrite-handle-vm_fault_retry-properly.patch mm-madvise-dont-perform-madvise-vma-walk-for-madv_populate_readwrite.patch mm-userfaultfd-dont-place-zeropages-when-zeropages-are-disallowed.patch s390-mm-re-enable-the-shared-zeropage-for-pv-and-skeys-kvm-guests.patch mm-convert-folio_estimated_sharers-to-folio_likely_mapped_shared.patch mm-convert-folio_estimated_sharers-to-folio_likely_mapped_shared-fix.patch selftests-memfd_secret-add-vmsplice-test.patch mm-merge-folio_is_secretmem-into-folio_fast_pin_allowed.patch

9 months, 2 weeks

2
1
0 0

[merged mm-hotfixes-stable] crash-use-macro-to-add-crashk_res-into-iomem-early-for-specific-arch.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: crash: use macro to add crashk_res into iomem early for specific arch has been removed from the -mm tree. Its filename was crash-use-macro-to-add-crashk_res-into-iomem-early-for-specific-arch.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: Baoquan He <bhe(a)redhat.com> Subject: crash: use macro to add crashk_res into iomem early for specific arch Date: Mon, 25 Mar 2024 09:50:50 +0800 There are regression reports[1][2] that crashkernel region on x86_64 can't be added into iomem tree sometime. This causes the later failure of kdump loading. This happened after commit 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") was merged. Even though, these reported issues are proved to be related to other component, they are just exposed after above commmit applied, I still would like to keep crashk_res and crashk_low_res being added into iomem early as before because the early adding has been always there on x86_64 and working very well. For safety of kdump, Let's change it back. Here, add a macro HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY to limit that only ARCH defining the macro can have the early adding crashk_res/_low_res into iomem. Then define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY on x86 to enable it. Note: In reserve_crashkernel_low(), there's a remnant of crashk_low_res handling which was mistakenly added back in commit 85fcde402db1 ("kexec: split crashkernel reservation code out from crash_core.c"). [1] [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data https://lore.kernel.org/all/Zfv8iCL6CT2JqLIC@darkstar.users.ipa.redhat.com/… [2] Question about Address Range Validation in Crash Kernel Allocation https://lore.kernel.org/all/4eeac1f733584855965a2ea62fa4da58@huawei.com/T/#u Link: https://lkml.kernel.org/r/ZgDYemRQ2jxjLkq+@MiWiFi-R3L-srv Fixes: 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Huacai Chen <chenhuacai(a)loongson.cn> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Jiri Bohac <jbohac(a)suse.cz> Cc: Li Huafei <lihuafei1(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/include/asm/crash_reserve.h | 2 ++ kernel/crash_reserve.c | 7 +++++++ 2 files changed, 9 insertions(+) --- a/arch/x86/include/asm/crash_reserve.h~crash-use-macro-to-add-crashk_res-into-iomem-early-for-specific-arch +++ a/arch/x86/include/asm/crash_reserve.h @@ -39,4 +39,6 @@ static inline unsigned long crash_low_si #endif } +#define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY + #endif /* _X86_CRASH_RESERVE_H */ --- a/kernel/crash_reserve.c~crash-use-macro-to-add-crashk_res-into-iomem-early-for-specific-arch +++ a/kernel/crash_reserve.c @@ -366,8 +366,10 @@ static int __init reserve_crashkernel_lo crashk_low_res.start = low_base; crashk_low_res.end = low_base + low_size - 1; +#ifdef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY insert_resource(&iomem_resource, &crashk_low_res); #endif +#endif return 0; } @@ -448,8 +450,12 @@ retry: crashk_res.start = crash_base; crashk_res.end = crash_base + crash_size - 1; +#ifdef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY + insert_resource(&iomem_resource, &crashk_res); +#endif } +#ifndef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY static __init int insert_crashkernel_resources(void) { if (crashk_res.start < crashk_res.end) @@ -462,3 +468,4 @@ static __init int insert_crashkernel_res } early_initcall(insert_crashkernel_resources); #endif +#endif _ Patches currently in -mm which might be from bhe(a)redhat.com are mm-vmallocc-optimize-to-reduce-arguments-of-alloc_vmap_area.patch x86-remove-unneeded-memblock_find_dma_reserve.patch mm-mm_initc-remove-the-useless-dma_reserve.patch mm-mm_initc-add-new-function-calc_nr_all_pages.patch mm-mm_initc-remove-meaningless-calculation-of-zone-managed_pages-in-free_area_init_core.patch mm-mm_initc-remove-unneeded-calc_memmap_size.patch mm-mm_initc-remove-arch_reserved_kernel_pages.patch

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-zswap-fix-data-loss-on-swp_synchronous_io-devices.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: zswap: fix data loss on SWP_SYNCHRONOUS_IO devices has been removed from the -mm tree. Its filename was mm-zswap-fix-data-loss-on-swp_synchronous_io-devices.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: Johannes Weiner <hannes(a)cmpxchg.org> Subject: mm: zswap: fix data loss on SWP_SYNCHRONOUS_IO devices Date: Sun, 24 Mar 2024 17:04:47 -0400 Zhongkun He reports data corruption when combining zswap with zram. The issue is the exclusive loads we're doing in zswap. They assume that all reads are going into the swapcache, which can assume authoritative ownership of the data and so the zswap copy can go. However, zram files are marked SWP_SYNCHRONOUS_IO, and faults will try to bypass the swapcache. This results in an optimistic read of the swap data into a page that will be dismissed if the fault fails due to races. In this case, zswap mustn't drop its authoritative copy. Link: https://lore.kernel.org/all/CACSyD1N+dUvsu8=zV9P691B9bVq33erwOXNTmEaUbi9DrD… Fixes: b9c91c43412f ("mm: zswap: support exclusive loads") Link: https://lkml.kernel.org/r/20240324210447.956973-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Zhongkun He <hezhongkun.hzk(a)bytedance.com> Tested-by: Zhongkun He <hezhongkun.hzk(a)bytedance.com> Acked-by: Yosry Ahmed <yosryahmed(a)google.com> Acked-by: Barry Song <baohua(a)kernel.org> Reviewed-by: Chengming Zhou <chengming.zhou(a)linux.dev> Reviewed-by: Nhat Pham <nphamcs(a)gmail.com> Acked-by: Chris Li <chrisl(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.5+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zswap.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/mm/zswap.c~mm-zswap-fix-data-loss-on-swp_synchronous_io-devices +++ a/mm/zswap.c @@ -1636,6 +1636,7 @@ bool zswap_load(struct folio *folio) swp_entry_t swp = folio->swap; pgoff_t offset = swp_offset(swp); struct page *page = &folio->page; + bool swapcache = folio_test_swapcache(folio); struct zswap_tree *tree = swap_zswap_tree(swp); struct zswap_entry *entry; u8 *dst; @@ -1648,7 +1649,20 @@ bool zswap_load(struct folio *folio) spin_unlock(&tree->lock); return false; } - zswap_rb_erase(&tree->rbroot, entry); + /* + * When reading into the swapcache, invalidate our entry. The + * swapcache can be the authoritative owner of the page and + * its mappings, and the pressure that results from having two + * in-memory copies outweighs any benefits of caching the + * compression work. + * + * (Most swapins go through the swapcache. The notable + * exception is the singleton fault on SWP_SYNCHRONOUS_IO + * files, which reads into a private page and may free it if + * the fault fails. We remain the primary owner of the entry.) + */ + if (swapcache) + zswap_rb_erase(&tree->rbroot, entry); spin_unlock(&tree->lock); if (entry->length) @@ -1663,9 +1677,10 @@ bool zswap_load(struct folio *folio) if (entry->objcg) count_objcg_event(entry->objcg, ZSWPIN); - zswap_entry_free(entry); - - folio_mark_dirty(folio); + if (swapcache) { + zswap_entry_free(entry); + folio_mark_dirty(folio); + } return true; } _ Patches currently in -mm which might be from hannes(a)cmpxchg.org are mm-zswap-optimize-zswap-pool-size-tracking.patch mm-zpool-return-pool-size-in-pages.patch mm-page_alloc-remove-pcppage-migratetype-caching.patch mm-page_alloc-optimize-free_unref_folios.patch mm-page_alloc-fix-up-block-types-when-merging-compatible-blocks.patch mm-page_alloc-move-free-pages-when-converting-block-during-isolation.patch mm-page_alloc-fix-move_freepages_block-range-error.patch mm-page_alloc-fix-freelist-movement-during-block-conversion.patch mm-page_alloc-close-migratetype-race-between-freeing-and-stealing.patch mm-page_isolation-prepare-for-hygienic-freelists.patch mm-page_isolation-prepare-for-hygienic-freelists-fix.patch mm-page_alloc-consolidate-free-page-accounting.patch

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] selftests-mm-fix-arm-related-issue-with-fork-after-pthread_create.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: fix ARM related issue with fork after pthread_create has been removed from the -mm tree. Its filename was selftests-mm-fix-arm-related-issue-with-fork-after-pthread_create.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 ARM related issue with fork after pthread_create Date: Mon, 25 Mar 2024 19:40:52 +0000 Following issue was observed while running the uffd-unit-tests selftest on ARM devices. On x86_64 no issues were detected: pthread_create followed by fork caused deadlock in certain cases wherein fork required some work to be completed by the created thread. Used synchronization to ensure that created thread's start function has started before invoking fork. [edliaw(a)google.com: refactored to use atomic_bool] Link: https://lkml.kernel.org/r/20240325194100.775052-1-edliaw@google.com Fixes: 760aee0b71e3 ("selftests/mm: add tests for RO pinning vs fork()") Signed-off-by: Lokesh Gidra <lokeshgidra(a)google.com> Signed-off-by: Edward Liaw <edliaw(a)google.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/uffd-common.c | 3 +++ tools/testing/selftests/mm/uffd-common.h | 2 ++ tools/testing/selftests/mm/uffd-unit-tests.c | 10 ++++++++++ 3 files changed, 15 insertions(+) --- a/tools/testing/selftests/mm/uffd-common.c~selftests-mm-fix-arm-related-issue-with-fork-after-pthread_create +++ a/tools/testing/selftests/mm/uffd-common.c @@ -18,6 +18,7 @@ bool test_uffdio_wp = true; unsigned long long *count_verify; uffd_test_ops_t *uffd_test_ops; uffd_test_case_ops_t *uffd_test_case_ops; +atomic_bool ready_for_fork; static int uffd_mem_fd_create(off_t mem_size, bool hugetlb) { @@ -518,6 +519,8 @@ void *uffd_poll_thread(void *arg) pollfd[1].fd = pipefd[cpu*2]; pollfd[1].events = POLLIN; + ready_for_fork = true; + for (;;) { ret = poll(pollfd, 2, -1); if (ret <= 0) { --- a/tools/testing/selftests/mm/uffd-common.h~selftests-mm-fix-arm-related-issue-with-fork-after-pthread_create +++ a/tools/testing/selftests/mm/uffd-common.h @@ -32,6 +32,7 @@ #include <inttypes.h> #include <stdint.h> #include <sys/random.h> +#include <stdatomic.h> #include "../kselftest.h" #include "vm_util.h" @@ -103,6 +104,7 @@ extern bool map_shared; extern bool test_uffdio_wp; extern unsigned long long *count_verify; extern volatile bool test_uffdio_copy_eexist; +extern atomic_bool ready_for_fork; extern uffd_test_ops_t anon_uffd_test_ops; extern uffd_test_ops_t shmem_uffd_test_ops; --- a/tools/testing/selftests/mm/uffd-unit-tests.c~selftests-mm-fix-arm-related-issue-with-fork-after-pthread_create +++ a/tools/testing/selftests/mm/uffd-unit-tests.c @@ -775,6 +775,8 @@ static void uffd_sigbus_test_common(bool char c; struct uffd_args args = { 0 }; + ready_for_fork = false; + fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK); if (uffd_register(uffd, area_dst, nr_pages * page_size, @@ -790,6 +792,9 @@ static void uffd_sigbus_test_common(bool if (pthread_create(&uffd_mon, NULL, uffd_poll_thread, &args)) err("uffd_poll_thread create"); + while (!ready_for_fork) + ; /* Wait for the poll_thread to start executing before forking */ + pid = fork(); if (pid < 0) err("fork"); @@ -829,6 +834,8 @@ static void uffd_events_test_common(bool char c; struct uffd_args args = { 0 }; + ready_for_fork = false; + fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK); if (uffd_register(uffd, area_dst, nr_pages * page_size, true, wp, false)) @@ -838,6 +845,9 @@ static void uffd_events_test_common(bool if (pthread_create(&uffd_mon, NULL, uffd_poll_thread, &args)) err("uffd_poll_thread create"); + while (!ready_for_fork) + ; /* Wait for the poll_thread to start executing before forking */ + pid = fork(); if (pid < 0) err("fork"); _ Patches currently in -mm which might be from edliaw(a)google.com are

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] hexagon-vmlinuxldss-handle-attributes-section.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: hexagon: vmlinux.lds.S: handle attributes section has been removed from the -mm tree. Its filename was hexagon-vmlinuxldss-handle-attributes-section.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: Nathan Chancellor <nathan(a)kernel.org> Subject: hexagon: vmlinux.lds.S: handle attributes section Date: Tue, 19 Mar 2024 17:37:46 -0700 After the linked LLVM change, the build fails with CONFIG_LD_ORPHAN_WARN_LEVEL="error", which happens with allmodconfig: ld.lld: error: vmlinux.a(init/main.o):(.hexagon.attributes) is being placed in '.hexagon.attributes' Handle the attributes section in a similar manner as arm and riscv by adding it after the primary ELF_DETAILS grouping in vmlinux.lds.S, which fixes the error. Link: https://lkml.kernel.org/r/20240319-hexagon-handle-attributes-section-vmlinu… Fixes: 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN") Link: https://github.com/llvm/llvm-project/commit/31f4b329c8234fab9afa59494d7f8bd… Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Reviewed-by: Brian Cain <bcain(a)quicinc.com> Cc: Bill Wendling <morbo(a)google.com> Cc: Justin Stitt <justinstitt(a)google.com> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/hexagon/kernel/vmlinux.lds.S | 1 + 1 file changed, 1 insertion(+) --- a/arch/hexagon/kernel/vmlinux.lds.S~hexagon-vmlinuxldss-handle-attributes-section +++ a/arch/hexagon/kernel/vmlinux.lds.S @@ -63,6 +63,7 @@ SECTIONS STABS_DEBUG DWARF_DEBUG ELF_DETAILS + .hexagon.attributes 0 : { *(.hexagon.attributes) } DISCARDS } _ Patches currently in -mm which might be from nathan(a)kernel.org are

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] tmpfs-fix-race-on-handling-dquot-rbtree.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: tmpfs: fix race on handling dquot rbtree has been removed from the -mm tree. Its filename was tmpfs-fix-race-on-handling-dquot-rbtree.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: Carlos Maiolino <cem(a)kernel.org> Subject: tmpfs: fix race on handling dquot rbtree Date: Wed, 20 Mar 2024 13:39:59 +0100 A syzkaller reproducer found a race while attempting to remove dquot information from the rb tree. Fetching the rb_tree root node must also be protected by the dqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot() will trigger a warning because it couldn't find a node in the tree, when the real reason was the root node changing before the search starts: Thread 1 Thread 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - fetch ROOT - Fetch ROOT - acquire dqio_sem - wait dqio_sem - do something, triger a tree rebalance - release dqio_sem - acquire dqio_sem - start searching for the node, but from the wrong location, missing the node, and triggering a warning. Link: https://lkml.kernel.org/r/20240320124011.398847-1-cem@kernel.org Fixes: eafc474e2029 ("shmem: prepare shmem quota infrastructure") Signed-off-by: Carlos Maiolino <cmaiolino(a)redhat.com> Reported-by: Ubisectech Sirius <bugreport(a)ubisectech.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem_quota.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/mm/shmem_quota.c~tmpfs-fix-race-on-handling-dquot-rbtree +++ a/mm/shmem_quota.c @@ -116,7 +116,7 @@ static int shmem_free_file_info(struct s static int shmem_get_next_id(struct super_block *sb, struct kqid *qid) { struct mem_dqinfo *info = sb_dqinfo(sb, qid->type); - struct rb_node *node = ((struct rb_root *)info->dqi_priv)->rb_node; + struct rb_node *node; qid_t id = from_kqid(&init_user_ns, *qid); struct quota_info *dqopt = sb_dqopt(sb); struct quota_id *entry = NULL; @@ -126,6 +126,7 @@ static int shmem_get_next_id(struct supe return -ESRCH; down_read(&dqopt->dqio_sem); + node = ((struct rb_root *)info->dqi_priv)->rb_node; while (node) { entry = rb_entry(node, struct quota_id, node); @@ -165,7 +166,7 @@ out_unlock: static int shmem_acquire_dquot(struct dquot *dquot) { struct mem_dqinfo *info = sb_dqinfo(dquot->dq_sb, dquot->dq_id.type); - struct rb_node **n = &((struct rb_root *)info->dqi_priv)->rb_node; + struct rb_node **n; struct shmem_sb_info *sbinfo = dquot->dq_sb->s_fs_info; struct rb_node *parent = NULL, *new_node = NULL; struct quota_id *new_entry, *entry; @@ -176,6 +177,8 @@ static int shmem_acquire_dquot(struct dq mutex_lock(&dquot->dq_lock); down_write(&dqopt->dqio_sem); + n = &((struct rb_root *)info->dqi_priv)->rb_node; + while (*n) { parent = *n; entry = rb_entry(parent, struct quota_id, node); @@ -264,7 +267,7 @@ static bool shmem_is_empty_dquot(struct static int shmem_release_dquot(struct dquot *dquot) { struct mem_dqinfo *info = sb_dqinfo(dquot->dq_sb, dquot->dq_id.type); - struct rb_node *node = ((struct rb_root *)info->dqi_priv)->rb_node; + struct rb_node *node; qid_t id = from_kqid(&init_user_ns, dquot->dq_id); struct quota_info *dqopt = sb_dqopt(dquot->dq_sb); struct quota_id *entry = NULL; @@ -275,6 +278,7 @@ static int shmem_release_dquot(struct dq goto out_dqlock; down_write(&dqopt->dqio_sem); + node = ((struct rb_root *)info->dqi_priv)->rb_node; while (node) { entry = rb_entry(node, struct quota_id, node); _ Patches currently in -mm which might be from cem(a)kernel.org are

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] selftests-mm-sigbus-wp-test-requires-uffd_feature_wp_hugetlbfs_shmem.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: sigbus-wp test requires UFFD_FEATURE_WP_HUGETLBFS_SHMEM has been removed from the -mm tree. Its filename was selftests-mm-sigbus-wp-test-requires-uffd_feature_wp_hugetlbfs_shmem.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: sigbus-wp test requires UFFD_FEATURE_WP_HUGETLBFS_SHMEM Date: Thu, 21 Mar 2024 23:20:21 +0000 The sigbus-wp test requires the UFFD_FEATURE_WP_HUGETLBFS_SHMEM flag for shmem and hugetlb targets. Otherwise it is not backwards compatible with kernels <5.19 and fails with EINVAL. Link: https://lkml.kernel.org/r/20240321232023.2064975-1-edliaw@google.com Fixes: 73c1ea939b65 ("selftests/mm: move uffd sig/events tests into uffd unit tests") Signed-off-by: Edward Liaw <edliaw(a)google.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Peter Xu <peterx(a)redhat.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/uffd-unit-tests.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/mm/uffd-unit-tests.c~selftests-mm-sigbus-wp-test-requires-uffd_feature_wp_hugetlbfs_shmem +++ a/tools/testing/selftests/mm/uffd-unit-tests.c @@ -1427,7 +1427,8 @@ uffd_test_case_t uffd_tests[] = { .uffd_fn = uffd_sigbus_wp_test, .mem_targets = MEM_ALL, .uffd_feature_required = UFFD_FEATURE_SIGBUS | - UFFD_FEATURE_EVENT_FORK | UFFD_FEATURE_PAGEFAULT_FLAG_WP, + UFFD_FEATURE_EVENT_FORK | UFFD_FEATURE_PAGEFAULT_FLAG_WP | + UFFD_FEATURE_WP_HUGETLBFS_SHMEM, }, { .name = "events", _ Patches currently in -mm which might be from edliaw(a)google.com are

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] arm-prctl-reject-pr_set_mdwe-on-pre-armv6.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ARM: prctl: reject PR_SET_MDWE on pre-ARMv6 has been removed from the -mm tree. Its filename was arm-prctl-reject-pr_set_mdwe-on-pre-armv6.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: Zev Weiss <zev(a)bewilderbeest.net> Subject: ARM: prctl: reject PR_SET_MDWE on pre-ARMv6 Date: Mon, 26 Feb 2024 17:35:42 -0800 On v5 and lower CPUs we can't provide MDWE protection, so ensure we fail any attempt to enable it via prctl(PR_SET_MDWE). Previously such an attempt would misleadingly succeed, leading to any subsequent mmap(PROT_READ|PROT_WRITE) or execve() failing unconditionally (the latter somewhat violently via force_fatal_sig(SIGSEGV) due to READ_IMPLIES_EXEC). Link: https://lkml.kernel.org/r/20240227013546.15769-6-zev@bewilderbeest.net Signed-off-by: Zev Weiss <zev(a)bewilderbeest.net> Cc: <stable(a)vger.kernel.org> [6.3+] Cc: Borislav Petkov <bp(a)alien8.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Florent Revest <revest(a)chromium.org> Cc: Helge Deller <deller(a)gmx.de> Cc: "James E.J. Bottomley" <James.Bottomley(a)HansenPartnership.com> Cc: Josh Triplett <josh(a)joshtriplett.org> Cc: Kees Cook <keescook(a)chromium.org> Cc: Miguel Ojeda <ojeda(a)kernel.org> Cc: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Ondrej Mosnacek <omosnace(a)redhat.com> Cc: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: Russell King (Oracle) <linux(a)armlinux.org.uk> Cc: Sam James <sam(a)gentoo.org> Cc: Stefan Roesch <shr(a)devkernel.io> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Yin Fengwei <fengwei.yin(a)intel.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm/include/asm/mman.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- /dev/null +++ a/arch/arm/include/asm/mman.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_MMAN_H__ +#define __ASM_MMAN_H__ + +#include <asm/system_info.h> +#include <uapi/asm/mman.h> + +static inline bool arch_memory_deny_write_exec_supported(void) +{ + return cpu_architecture() >= CPU_ARCH_ARMv6; +} +#define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported + +#endif /* __ASM_MMAN_H__ */ _ Patches currently in -mm which might be from zev(a)bewilderbeest.net are

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] prctl-generalize-pr_set_mdwe-support-check-to-be-per-arch.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: prctl: generalize PR_SET_MDWE support check to be per-arch has been removed from the -mm tree. Its filename was prctl-generalize-pr_set_mdwe-support-check-to-be-per-arch.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: Zev Weiss <zev(a)bewilderbeest.net> Subject: prctl: generalize PR_SET_MDWE support check to be per-arch Date: Mon, 26 Feb 2024 17:35:41 -0800 Patch series "ARM: prctl: Reject PR_SET_MDWE where not supported". I noticed after a recent kernel update that my ARM926 system started segfaulting on any execve() after calling prctl(PR_SET_MDWE). After some investigation it appears that ARMv5 is incapable of providing the appropriate protections for MDWE, since any readable memory is also implicitly executable. The prctl_set_mdwe() function already had some special-case logic added disabling it on PARISC (commit 793838138c15, "prctl: Disable prctl(PR_SET_MDWE) on parisc"); this patch series (1) generalizes that check to use an arch_*() function, and (2) adds a corresponding override for ARM to disable MDWE on pre-ARMv6 CPUs. With the series applied, prctl(PR_SET_MDWE) is rejected on ARMv5 and subsequent execve() calls (as well as mmap(PROT_READ|PROT_WRITE)) can succeed instead of unconditionally failing; on ARMv6 the prctl works as it did previously. [0] https://lore.kernel.org/all/2023112456-linked-nape-bf19@gregkh/ This patch (of 2): There exist systems other than PARISC where MDWE may not be feasible to support; rather than cluttering up the generic code with additional arch-specific logic let's add a generic function for checking MDWE support and allow each arch to override it as needed. Link: https://lkml.kernel.org/r/20240227013546.15769-4-zev@bewilderbeest.net Link: https://lkml.kernel.org/r/20240227013546.15769-5-zev@bewilderbeest.net Signed-off-by: Zev Weiss <zev(a)bewilderbeest.net> Acked-by: Helge Deller <deller(a)gmx.de> [parisc] Cc: Borislav Petkov <bp(a)alien8.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Florent Revest <revest(a)chromium.org> Cc: "James E.J. Bottomley" <James.Bottomley(a)HansenPartnership.com> Cc: Josh Triplett <josh(a)joshtriplett.org> Cc: Kees Cook <keescook(a)chromium.org> Cc: Miguel Ojeda <ojeda(a)kernel.org> Cc: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Ondrej Mosnacek <omosnace(a)redhat.com> Cc: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: Russell King (Oracle) <linux(a)armlinux.org.uk> Cc: Sam James <sam(a)gentoo.org> Cc: Stefan Roesch <shr(a)devkernel.io> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Yin Fengwei <fengwei.yin(a)intel.com> Cc: <stable(a)vger.kernel.org> [6.3+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/parisc/include/asm/mman.h | 14 ++++++++++++++ include/linux/mman.h | 8 ++++++++ kernel/sys.c | 7 +++++-- 3 files changed, 27 insertions(+), 2 deletions(-) --- /dev/null +++ a/arch/parisc/include/asm/mman.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_MMAN_H__ +#define __ASM_MMAN_H__ + +#include <uapi/asm/mman.h> + +/* PARISC cannot allow mdwe as it needs writable stacks */ +static inline bool arch_memory_deny_write_exec_supported(void) +{ + return false; +} +#define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported + +#endif /* __ASM_MMAN_H__ */ --- a/include/linux/mman.h~prctl-generalize-pr_set_mdwe-support-check-to-be-per-arch +++ a/include/linux/mman.h @@ -162,6 +162,14 @@ calc_vm_flag_bits(unsigned long flags) unsigned long vm_commit_limit(void); +#ifndef arch_memory_deny_write_exec_supported +static inline bool arch_memory_deny_write_exec_supported(void) +{ + return true; +} +#define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported +#endif + /* * Denies creating a writable executable mapping or gaining executable permissions. * --- a/kernel/sys.c~prctl-generalize-pr_set_mdwe-support-check-to-be-per-arch +++ a/kernel/sys.c @@ -2408,8 +2408,11 @@ static inline int prctl_set_mdwe(unsigne if (bits & PR_MDWE_NO_INHERIT && !(bits & PR_MDWE_REFUSE_EXEC_GAIN)) return -EINVAL; - /* PARISC cannot allow mdwe as it needs writable stacks */ - if (IS_ENABLED(CONFIG_PARISC)) + /* + * EOPNOTSUPP might be more appropriate here in principle, but + * existing userspace depends on EINVAL specifically. + */ + if (!arch_memory_deny_write_exec_supported()) return -EINVAL; current_bits = get_current_mdwe(); _ Patches currently in -mm which might be from zev(a)bewilderbeest.net are

9 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024