January 2024 - Linux-stable-mirror

[merged mm-stable] selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory has been removed from the -mm tree. Its filename was selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory Date: Mon, 22 Jan 2024 12:05:54 +0000 ksm_tests was previously mmapping a region of memory, aligning the returned pointer to a PMD boundary, then setting MADV_HUGEPAGE, but was setting it past the end of the mmapped area due to not taking the pointer alignment into consideration. Fix this behaviour. Up until commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries"), this buggy behavior was (usually) masked because the alignment difference was always less than PMD-size. But since the mentioned commit, `ksm_tests -H -s 100` started failing. Link: https://lkml.kernel.org/r/20240122120554.3108022-1-ryan.roberts@arm.com Fixes: 325254899684 ("selftests: vm: add KSM huge pages merging time test") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Pedro Demarchi Gomes <pedrodemargomes(a)gmail.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/ksm_tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/mm/ksm_tests.c~selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory +++ a/tools/testing/selftests/mm/ksm_tests.c @@ -566,7 +566,7 @@ static int ksm_merge_hugepages_time(int if (map_ptr_orig == MAP_FAILED) err(2, "initial mmap"); - if (madvise(map_ptr, len + HPAGE_SIZE, MADV_HUGEPAGE)) + if (madvise(map_ptr, len, MADV_HUGEPAGE)) err(2, "MADV_HUGEPAGE"); pagemap_fd = open("/proc/self/pagemap", O_RDONLY); _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-userfaultfd-uffdio_move-implementation-should-use-ptep_get.patch tools-mm-add-thpmaps-script-to-dump-thp-usage-info.patch arm64-mm-make-set_ptes-robust-when-oas-cross-48-bit-boundary.patch

1 year, 3 months

1
0
0 0

[merged mm-stable] scs-add-config_mmu-dependency-for-vfree_atomic.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: scs: add CONFIG_MMU dependency for vfree_atomic() has been removed from the -mm tree. Its filename was scs-add-config_mmu-dependency-for-vfree_atomic.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Samuel Holland <samuel.holland(a)sifive.com> Subject: scs: add CONFIG_MMU dependency for vfree_atomic() Date: Mon, 22 Jan 2024 09:52:01 -0800 The shadow call stack implementation fails to build without CONFIG_MMU: ld.lld: error: undefined symbol: vfree_atomic >>> referenced by scs.c >>> kernel/scs.o:(scs_free) in archive vmlinux.a Link: https://lkml.kernel.org/r/20240122175204.2371009-1-samuel.holland@sifive.com Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks") Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> Reviewed-by: Sami Tolvanen <samitolvanen(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/arch/Kconfig~scs-add-config_mmu-dependency-for-vfree_atomic +++ a/arch/Kconfig @@ -673,6 +673,7 @@ config SHADOW_CALL_STACK bool "Shadow Call Stack" depends on ARCH_SUPPORTS_SHADOW_CALL_STACK depends on DYNAMIC_FTRACE_WITH_ARGS || DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER + depends on MMU help This option enables the compiler's Shadow Call Stack, which uses a shadow stack to protect function return addresses from _ Patches currently in -mm which might be from samuel.holland(a)sifive.com are

1 year, 3 months

1
0
0 0

[merged mm-stable] mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again has been removed from the -mm tree. Its filename was mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: "Zach O'Keefe" <zokeefe(a)google.com> Subject: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Date: Thu, 18 Jan 2024 10:19:53 -0800 (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the "is this a safe division" check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) Link: https://lkml.kernel.org/r/20240118181954.1415197-1-zokeefe@google.com Fixes: f6789593d5ce ("mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()") Signed-off-by: Zach O'Keefe <zokeefe(a)google.com> Cc: Maxim Patlasov <MPatlasov(a)parallels.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page-writeback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page-writeback.c~mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again +++ a/mm/page-writeback.c @@ -1638,7 +1638,7 @@ static inline void wb_dirty_limits(struc */ dtc->wb_thresh = __wb_calc_thresh(dtc); dtc->wb_bg_thresh = dtc->thresh ? - div_u64((u64)dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; + div64_u64(dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; /* * In order to avoid the stacked BDI deadlock we need _ Patches currently in -mm which might be from zokeefe(a)google.com are

1 year, 3 months

1
0
0 0

[merged mm-stable] selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests: mm: fix map_hugetlb failure on 64K page size systems has been removed from the -mm tree. Its filename was selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Nico Pache <npache(a)redhat.com> Subject: selftests: mm: fix map_hugetlb failure on 64K page size systems Date: Fri, 19 Jan 2024 06:14:29 -0700 On systems with 64k page size and 512M huge page sizes, the allocation and test succeeds but errors out at the munmap. As the comment states, munmap will failure if its not HUGEPAGE aligned. This is due to the length of the mapping being 1/2 the size of the hugepage causing the munmap to not be hugepage aligned. Fix this by making the mapping length the full hugepage if the hugepage is larger than the length of the mapping. Link: https://lkml.kernel.org/r/20240119131429.172448-1-npache@redhat.com Signed-off-by: Nico Pache <npache(a)redhat.com> Cc: Donet Tom <donettom(a)linux.vnet.ibm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Christophe Leroy <christophe.leroy(a)c-s.fr> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/map_hugetlb.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/tools/testing/selftests/mm/map_hugetlb.c~selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems +++ a/tools/testing/selftests/mm/map_hugetlb.c @@ -15,6 +15,7 @@ #include <unistd.h> #include <sys/mman.h> #include <fcntl.h> +#include "vm_util.h" #define LENGTH (256UL*1024*1024) #define PROTECTION (PROT_READ | PROT_WRITE) @@ -58,10 +59,16 @@ int main(int argc, char **argv) { void *addr; int ret; + size_t hugepage_size; size_t length = LENGTH; int flags = FLAGS; int shift = 0; + hugepage_size = default_huge_page_size(); + /* munmap with fail if the length is not page aligned */ + if (hugepage_size > length) + length = hugepage_size; + if (argc > 1) length = atol(argv[1]) << 20; if (argc > 2) { _ Patches currently in -mm which might be from npache(a)redhat.com are selftests-mm-perform-some-system-cleanup-before-using-hugepages.patch

1 year, 3 months

1
0
0 0

[merged mm-stable] selftests-mm-switch-to-bash-from-sh.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: switch to bash from sh has been removed from the -mm tree. Its filename was selftests-mm-switch-to-bash-from-sh.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Subject: selftests/mm: switch to bash from sh Date: Tue, 16 Jan 2024 14:04:54 +0500 Running charge_reserved_hugetlb.sh generates errors if sh is set to dash: ./charge_reserved_hugetlb.sh: 9: [[: not found ./charge_reserved_hugetlb.sh: 19: [[: not found ./charge_reserved_hugetlb.sh: 27: [[: not found ./charge_reserved_hugetlb.sh: 37: [[: not found ./charge_reserved_hugetlb.sh: 45: Syntax error: "(" unexpected Switch to using /bin/bash instead of /bin/sh. Make the switch for write_hugetlb_memory.sh as well which is called from charge_reserved_hugetlb.sh. Link: https://lkml.kernel.org/r/20240116090455.3407378-1-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/charge_reserved_hugetlb.sh | 2 +- tools/testing/selftests/mm/write_hugetlb_memory.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh~selftests-mm-switch-to-bash-from-sh +++ a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # SPDX-License-Identifier: GPL-2.0 # Kselftest framework requirement - SKIP code is 4. --- a/tools/testing/selftests/mm/write_hugetlb_memory.sh~selftests-mm-switch-to-bash-from-sh +++ a/tools/testing/selftests/mm/write_hugetlb_memory.sh @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # SPDX-License-Identifier: GPL-2.0 set -e _ Patches currently in -mm which might be from usama.anjum(a)collabora.com are selftests-core-include-linux-close_rangeh-for-close_range_-macros.patch selftests-mm-hugetlb_reparenting_test-do-not-unmount.patch selftests-mm-run_vmtests-remove-sudo-and-conform-to-tap.patch selftests-mm-save-and-restore-nr_hugepages-value.patch selftests-mm-protection_keys-save-restore-nr_hugepages-settings.patch selftests-mm-run_vmtestssh-add-missing-tests.patch

1 year, 3 months

1
0
0 0

[merged mm-stable] readahead-avoid-multiple-marked-readahead-pages.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: readahead: avoid multiple marked readahead pages has been removed from the -mm tree. Its filename was readahead-avoid-multiple-marked-readahead-pages.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jan Kara <jack(a)suse.cz> Subject: readahead: avoid multiple marked readahead pages Date: Thu, 4 Jan 2024 09:58:39 +0100 ra_alloc_folio() marks a page that should trigger next round of async readahead. However it rounds up computed index to the order of page being allocated. This can however lead to multiple consecutive pages being marked with readahead flag. Consider situation with index == 1, mark == 1, order == 0. We insert order 0 page at index 1 and mark it. Then we bump order to 1, index to 2, mark (still == 1) is rounded up to 2 so page at index 2 is marked as well. Then we bump order to 2, index is incremented to 4, mark gets rounded to 4 so page at index 4 is marked as well. The fact that multiple pages get marked within a single readahead window confuses the readahead logic and results in readahead window being trimmed back to 1. This situation is triggered in particular when maximum readahead window size is not a power of two (in the observed case it was 768 KB) and as a result sequential read throughput suffers. Fix the problem by rounding 'mark' down instead of up. Because the index is naturally aligned to 'order', we are guaranteed 'rounded mark' == index iff 'mark' is within the page we are allocating at 'index' and thus exactly one page is marked with readahead flag as required by the readahead code and sequential read performance is restored. This effectively reverts part of commit b9ff43dd2743 ("mm/readahead: Fix readahead with large folios"). The commit changed the rounding with the rationale: "... we were setting the readahead flag on the folio which contains the last byte read from the block. This is wrong because we will trigger readahead at the end of the read without waiting to see if a subsequent read is going to use the pages we just read." Although this is true, the fact is this was always the case with read sizes not aligned to folio boundaries and large folios in the page cache just make the situation more obvious (and frequent). Also for sequential read workloads it is better to trigger the readahead earlier rather than later. It is true that the difference in the rounding and thus earlier triggering of the readahead can result in reading more for semi-random workloads. However workloads really suffering from this seem to be rare. In particular I have verified that the workload described in commit b9ff43dd2743 ("mm/readahead: Fix readahead with large folios") of reading random 100k blocks from a file like: [reader] bs=100k rw=randread numjobs=1 size=64g runtime=60s is not impacted by the rounding change and achieves ~70MB/s in both cases. [jack(a)suse.cz: fix one more place where mark rounding was done as well] Link: https://lkml.kernel.org/r/20240123153254.5206-1-jack@suse.cz Link: https://lkml.kernel.org/r/20240104085839.21029-1-jack@suse.cz Fixes: b9ff43dd2743 ("mm/readahead: Fix readahead with large folios") Signed-off-by: Jan Kara <jack(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Guo Xuenan <guoxuenan(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/readahead.c~readahead-avoid-multiple-marked-readahead-pages +++ a/mm/readahead.c @@ -469,7 +469,7 @@ static inline int ra_alloc_folio(struct if (!folio) return -ENOMEM; - mark = round_up(mark, 1UL << order); + mark = round_down(mark, 1UL << order); if (index == mark) folio_set_readahead(folio); err = filemap_add_folio(ractl->mapping, folio, index, gfp); @@ -575,7 +575,7 @@ static void ondemand_readahead(struct re * It's the expected callback index, assume sequential access. * Ramp up sizes, and push forward the readahead window. */ - expected = round_up(ra->start + ra->size - ra->async_size, + expected = round_down(ra->start + ra->size - ra->async_size, 1UL << order); if (index == expected || index == (ra->start + ra->size)) { ra->start += ra->size; _ Patches currently in -mm which might be from jack(a)suse.cz are

1 year, 3 months

1
0
0 0

[merged mm-stable] fs-hugetlbfs-inodec-mm-memory-failurec-fix-hugetlbfs-hwpoison-handling.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/hugetlbfs/inode.c: mm/memory-failure.c: fix hugetlbfs hwpoison handling has been removed from the -mm tree. Its filename was fs-hugetlbfs-inodec-mm-memory-failurec-fix-hugetlbfs-hwpoison-handling.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Subject: fs/hugetlbfs/inode.c: mm/memory-failure.c: fix hugetlbfs hwpoison handling Date: Fri, 12 Jan 2024 10:08:40 -0800 has_extra_refcount() makes the assumption that the page cache adds a ref count of 1 and subtracts this in the extra_pins case. Commit a08c7193e4f1 (mm/filemap: remove hugetlb special casing in filemap.c) modifies __filemap_add_folio() by calling folio_ref_add(folio, nr); for all cases (including hugtetlb) where nr is the number of pages in the folio. We should adjust the number of references coming from the page cache by subtracing the number of pages rather than 1. In hugetlbfs_read_iter(), folio_test_has_hwpoisoned() is testing the wrong flag as, in the hugetlb case, memory-failure code calls folio_test_set_hwpoison() to indicate poison. folio_test_hwpoison() is the correct function to test for that flag. After these fixes, the hugetlb hwpoison read selftest passes all cases. Link: https://lkml.kernel.org/r/20240112180840.367006-1-sidhartha.kumar@oracle.com Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") Signed-off-by: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Closes: https://lore.kernel.org/linux-mm/20230713001833.3778937-1-jiaqiyan@google.c… Reported-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Tested-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Acked-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: James Houghton <jthoughton(a)google.com> Cc: Jiaqi Yan <jiaqiyan(a)google.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Cc: <stable(a)vger.kernel.org> [6.7+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/hugetlbfs/inode.c | 2 +- mm/memory-failure.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/fs/hugetlbfs/inode.c~fs-hugetlbfs-inodec-mm-memory-failurec-fix-hugetlbfs-hwpoison-handling +++ a/fs/hugetlbfs/inode.c @@ -340,7 +340,7 @@ static ssize_t hugetlbfs_read_iter(struc } else { folio_unlock(folio); - if (!folio_test_has_hwpoisoned(folio)) + if (!folio_test_hwpoison(folio)) want = nr; else { /* --- a/mm/memory-failure.c~fs-hugetlbfs-inodec-mm-memory-failurec-fix-hugetlbfs-hwpoison-handling +++ a/mm/memory-failure.c @@ -982,7 +982,7 @@ static bool has_extra_refcount(struct pa int count = page_count(p) - 1; if (extra_pins) - count -= 1; + count -= folio_nr_pages(page_folio(p)); if (count > 0) { pr_err("%#lx: %s still referenced by %d users\n", _ Patches currently in -mm which might be from sidhartha.kumar(a)oracle.com are maple_tree-fix-comment-describing-mas_node_count_gfp.patch

1 year, 3 months

1
0
0 0

[to-be-updated] revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" has been removed from the -mm tree. Its filename was revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: "T.J. Mercier" <tjmercier(a)google.com> Subject: Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" Date: Sun, 21 Jan 2024 21:44:12 +0000 This reverts commit 0388536ac29104a478c79b3869541524caec28eb. Proactive reclaim on the root cgroup is 10x slower after this patch when MGLRU is enabled, and completion times for proactive reclaim on much smaller non-root cgroups take ~30% longer (with or without MGLRU). With root reclaim before the patch, I observe average reclaim rates of ~70k pages/sec before try_to_free_mem_cgroup_pages starts to fail and the nr_retries counter starts to decrement, eventually ending the proactive reclaim attempt. After the patch the reclaim rate is consistently ~6.6k pages/sec due to the reduced nr_pages value causing scan aborts as soon as SWAP_CLUSTER_MAX pages are reclaimed. The proactive reclaim doesn't complete after several minutes because try_to_free_mem_cgroup_pages is still capable of reclaiming pages in tiny SWAP_CLUSTER_MAX page chunks and nr_retries is never decremented. The docs for memory.reclaim say, "the kernel can over or under reclaim from the target cgroup" which this patch was trying to fix. Revert it until a less costly solution is found. Link: https://lkml.kernel.org/r/20240121214413.833776-1-tjmercier@google.com Fixes: 0388536ac291 ("mm:vmscan: fix inaccurate reclaim during proactive reclaim") Signed-off-by: T.J. Mercier <tjmercier(a)google.com> Cc: Efly Young <yangyifei03(a)kuaishou.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: T.J. Mercier <tjmercier(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/memcontrol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/memcontrol.c~revert-mm-vmscan-fix-inaccurate-reclaim-during-proactive-reclaim +++ a/mm/memcontrol.c @@ -6977,8 +6977,8 @@ static ssize_t memory_reclaim(struct ker lru_add_drain_all(); reclaimed = try_to_free_mem_cgroup_pages(memcg, - min(nr_to_reclaim - nr_reclaimed, SWAP_CLUSTER_MAX), - GFP_KERNEL, reclaim_options); + nr_to_reclaim - nr_reclaimed, + GFP_KERNEL, reclaim_options); if (!reclaimed && !nr_retries--) return -EAGAIN; _ Patches currently in -mm which might be from tjmercier(a)google.com are

1 year, 3 months

1
0
0 0

+ nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix data corruption in dsync block recovery for small block sizes has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.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: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Subject: nilfs2: fix data corruption in dsync block recovery for small block sizes Date: Wed, 24 Jan 2024 21:19:36 +0900 The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/recovery.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/fs/nilfs2/recovery.c~nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes +++ a/fs/nilfs2/recovery.c @@ -472,9 +472,10 @@ static int nilfs_prepare_segment_for_rec static int nilfs_recovery_copy_block(struct the_nilfs *nilfs, struct nilfs_recovery_block *rb, - struct page *page) + loff_t pos, struct page *page) { struct buffer_head *bh_org; + size_t from = pos & ~PAGE_MASK; void *kaddr; bh_org = __bread(nilfs->ns_bdev, rb->blocknr, nilfs->ns_blocksize); @@ -482,7 +483,7 @@ static int nilfs_recovery_copy_block(str return -EIO; kaddr = kmap_atomic(page); - memcpy(kaddr + bh_offset(bh_org), bh_org->b_data, bh_org->b_size); + memcpy(kaddr + from, bh_org->b_data, bh_org->b_size); kunmap_atomic(kaddr); brelse(bh_org); return 0; @@ -521,7 +522,7 @@ static int nilfs_recover_dsync_blocks(st goto failed_inode; } - err = nilfs_recovery_copy_block(nilfs, rb, page); + err = nilfs_recovery_copy_block(nilfs, rb, pos, page); if (unlikely(err)) goto failed_page; _ Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch nilfs2-convert-recovery-logic-to-use-kmap_local.patch nilfs2-convert-segment-buffer-to-use-kmap_local.patch nilfs2-convert-nilfs_copy_buffer-to-use-kmap_local.patch nilfs2-convert-metadata-file-common-code-to-use-kmap_local.patch nilfs2-convert-sufile-to-use-kmap_local.patch nilfs2-convert-persistent-object-allocator-to-use-kmap_local.patch nilfs2-convert-dat-to-use-kmap_local.patch nilfs2-move-nilfs_bmap_write-call-out-of-nilfs_write_inode_common.patch nilfs2-do-not-acquire-rwsem-in-nilfs_bmap_write.patch nilfs2-convert-ifile-to-use-kmap_local.patch nilfs2-localize-highmem-mapping-for-checkpoint-creation-within-cpfile.patch nilfs2-localize-highmem-mapping-for-checkpoint-finalization-within-cpfile.patch nilfs2-localize-highmem-mapping-for-checkpoint-reading-within-cpfile.patch nilfs2-remove-nilfs_cpfile_getput_checkpoint.patch nilfs2-convert-cpfile-to-use-kmap_local.patch

1 year, 3 months

1
0
0 0

[PATCH net v2 0/2] nfp: flower: a few small conntrack offload fixes

by Louis Peens

This small series addresses two bugs in the nfp conntrack offloading code. The first patch is a check to prevent offloading for a case which is currently not supported by the nfp. The second patch fixes up parsing of layer4 mangling code so it can be correctly offloaded. Since the masks are an inverse mask and we are shifting it so it can be packed together with the destination we effectively need to 'clear' the lower bits of the mask by setting it to 0xFFFF. Changes since v1: - Added inline comment to the second patch - Expanded the commit message to better explain the mask setting in the second patch. Hui Zhou (2): nfp: flower: add hardware offload check for post ct entry nfp: flower: fix hardware offload for the transfer layer port .../ethernet/netronome/nfp/flower/conntrack.c | 46 +++++++++++++++++-- 1 file changed, 43 insertions(+), 3 deletions(-) -- 2.34.1

1 year, 3 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024