February 2024 - Linux-stable-mirror

[PATCH net] xfrm: Avoid clang fortify warning in copy_to_user_tmpl()

by Nathan Chancellor

After a couple recent changes in LLVM, there is a warning (or error with CONFIG_WERROR=y or W=e) from the compile time fortify source routines, specifically the memset() in copy_to_user_tmpl(). In file included from net/xfrm/xfrm_user.c:14: ... include/linux/fortify-string.h:438:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 438 | __write_overflow_field(p_size_field, size); | ^ 1 error generated. While ->xfrm_nr has been validated against XFRM_MAX_DEPTH when its value is first assigned in copy_templates() by calling validate_tmpl() first (so there should not be any issue in practice), LLVM/clang cannot really deduce that across the boundaries of these functions. Without that knowledge, it cannot assume that the loop stops before i is greater than XFRM_MAX_DEPTH, which would indeed result a stack buffer overflow in the memset(). To make the bounds of ->xfrm_nr clear to the compiler and add additional defense in case copy_to_user_tmpl() is ever used in a path where ->xfrm_nr has not been properly validated against XFRM_MAX_DEPTH first, add an explicit bound check and early return, which clears up the warning. Cc: stable(a)vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1985 Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- net/xfrm/xfrm_user.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index f037be190bae..912c1189ba41 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -2017,6 +2017,9 @@ static int copy_to_user_tmpl(struct xfrm_policy *xp, struct sk_buff *skb) if (xp->xfrm_nr == 0) return 0; + if (xp->xfrm_nr > XFRM_MAX_DEPTH) + return -ENOBUFS; + for (i = 0; i < xp->xfrm_nr; i++) { struct xfrm_user_tmpl *up = &vec[i]; struct xfrm_tmpl *kp = &xp->xfrm_vec[i]; --- base-commit: 14dec56fdd4c70a0ebe40077368e367421ea6fef change-id: 20240221-xfrm-avoid-clang-fortify-warning-copy_to_user_tmpl-40cb10b003e3 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 year, 8 months

3
2
0 0

[PATCH 5.15 0/1] rcutorture: Add missing return and use __func__ in warning

by Daniil Dulov

Svacer reports a potential division by zero at rcu_torture_writer() in 5.15 stable release. The problem has been fixed by the following patch that can be cleanly applied to 5.15 branch.

1 year, 8 months

1
1
0 0

FAILED: patch "[PATCH] mm: zswap: fix missing folio cleanup in writeback race path" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x e3b63e966cac0bf78aaa1efede1827a252815a1d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024022612-uncloak-pretext-f4a2@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: e3b63e966cac ("mm: zswap: fix missing folio cleanup in writeback race path") 96c7b0b42239 ("mm: return the folio from __read_swap_cache_async()") e947ba0bbf47 ("mm/zswap: cleanup zswap_writeback_entry()") 32acba4c0483 ("mm/zswap: refactor out __zswap_load()") c75f5c1e0f1d ("mm/zswap: reuse dstmem when decompress") b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") a65b0e7607cc ("zswap: make shrinking memcg-aware") ddc1a5cbc05d ("mempolicy: alloc_pages_mpol() for NUMA policy without vma") 23e4883248f0 ("mm: add page_rmappable_folio() wrapper") c36f6e6dff4d ("mempolicy trivia: slightly more consistent naming") 7f1ee4e20708 ("mempolicy trivia: delete those ancient pr_debug()s") 1cb5d11a370f ("mempolicy: fix migrate_pages(2) syscall return nr_failed") 3657fdc2451a ("mm: move vma_policy() and anon_vma_name() decls to mm_types.h") 3022fd7af960 ("shmem: _add_to_page_cache() before shmem_inode_acct_blocks()") 054a9f7ccd0a ("shmem: move memcg charge out of shmem_add_to_page_cache()") 4199f51a7eb2 ("shmem: shmem_acct_blocks() and shmem_inode_acct_blocks()") e3e1a5067fd2 ("shmem: remove vma arg from shmem_get_folio_gfp()") 75c70128a673 ("mm: mempolicy: make mpol_misplaced() to take a folio") cda6d93672ac ("mm: memory: make numa_migrate_prep() to take a folio") 6695cf68b15c ("mm: memory: use a folio in do_numa_page()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e3b63e966cac0bf78aaa1efede1827a252815a1d Mon Sep 17 00:00:00 2001 From: Yosry Ahmed <yosryahmed(a)google.com> Date: Thu, 25 Jan 2024 08:51:27 +0000 Subject: [PATCH] mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com Fixes: 04fc7816089c ("mm: fix zswap writeback race condition") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Reviewed-by: Chengming Zhou <zhouchengming(a)bytedance.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Nhat Pham <nphamcs(a)gmail.com> Cc: Domenico Cerasuolo <cerasuolodomenico(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/zswap.c b/mm/zswap.c index 350dd2fc8159..d2423247acfd 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1440,6 +1440,8 @@ static int zswap_writeback_entry(struct zswap_entry *entry, if (zswap_rb_search(&tree->rbroot, swp_offset(entry->swpentry)) != entry) { spin_unlock(&tree->lock); delete_from_swap_cache(folio); + folio_unlock(folio); + folio_put(folio); return -ENOMEM; } spin_unlock(&tree->lock);

1 year, 8 months

3
6
0 0

FAILED: patch "[PATCH] mm: zswap: fix missing folio cleanup in writeback race path" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x e3b63e966cac0bf78aaa1efede1827a252815a1d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024022611-tropics-deferred-2483@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: e3b63e966cac ("mm: zswap: fix missing folio cleanup in writeback race path") 96c7b0b42239 ("mm: return the folio from __read_swap_cache_async()") e947ba0bbf47 ("mm/zswap: cleanup zswap_writeback_entry()") 32acba4c0483 ("mm/zswap: refactor out __zswap_load()") c75f5c1e0f1d ("mm/zswap: reuse dstmem when decompress") b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") a65b0e7607cc ("zswap: make shrinking memcg-aware") ddc1a5cbc05d ("mempolicy: alloc_pages_mpol() for NUMA policy without vma") 23e4883248f0 ("mm: add page_rmappable_folio() wrapper") c36f6e6dff4d ("mempolicy trivia: slightly more consistent naming") 7f1ee4e20708 ("mempolicy trivia: delete those ancient pr_debug()s") 1cb5d11a370f ("mempolicy: fix migrate_pages(2) syscall return nr_failed") 3657fdc2451a ("mm: move vma_policy() and anon_vma_name() decls to mm_types.h") 3022fd7af960 ("shmem: _add_to_page_cache() before shmem_inode_acct_blocks()") 054a9f7ccd0a ("shmem: move memcg charge out of shmem_add_to_page_cache()") 4199f51a7eb2 ("shmem: shmem_acct_blocks() and shmem_inode_acct_blocks()") e3e1a5067fd2 ("shmem: remove vma arg from shmem_get_folio_gfp()") 75c70128a673 ("mm: mempolicy: make mpol_misplaced() to take a folio") cda6d93672ac ("mm: memory: make numa_migrate_prep() to take a folio") 6695cf68b15c ("mm: memory: use a folio in do_numa_page()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e3b63e966cac0bf78aaa1efede1827a252815a1d Mon Sep 17 00:00:00 2001 From: Yosry Ahmed <yosryahmed(a)google.com> Date: Thu, 25 Jan 2024 08:51:27 +0000 Subject: [PATCH] mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com Fixes: 04fc7816089c ("mm: fix zswap writeback race condition") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Reviewed-by: Chengming Zhou <zhouchengming(a)bytedance.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Nhat Pham <nphamcs(a)gmail.com> Cc: Domenico Cerasuolo <cerasuolodomenico(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/zswap.c b/mm/zswap.c index 350dd2fc8159..d2423247acfd 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1440,6 +1440,8 @@ static int zswap_writeback_entry(struct zswap_entry *entry, if (zswap_rb_search(&tree->rbroot, swp_offset(entry->swpentry)) != entry) { spin_unlock(&tree->lock); delete_from_swap_cache(folio); + folio_unlock(folio); + folio_put(folio); return -ENOMEM; } spin_unlock(&tree->lock);

1 year, 8 months

4
4
0 0

FAILED: patch "[PATCH] mm/zswap: invalidate duplicate entry when !zswap_enabled" failed to apply to 6.7-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.7-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.7.y git checkout FETCH_HEAD git cherry-pick -x 678e54d4bb9a4822f8ae99690ac131c5d490cdb1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024022622-agony-salvaging-5082@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^.. Possible dependencies: 678e54d4bb9a ("mm/zswap: invalidate duplicate entry when !zswap_enabled") a65b0e7607cc ("zswap: make shrinking memcg-aware") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 678e54d4bb9a4822f8ae99690ac131c5d490cdb1 Mon Sep 17 00:00:00 2001 From: Chengming Zhou <zhouchengming(a)bytedance.com> Date: Thu, 8 Feb 2024 02:32:54 +0000 Subject: [PATCH] mm/zswap: invalidate duplicate entry when !zswap_enabled We have to invalidate any duplicate entry even when !zswap_enabled since zswap can be disabled anytime. If the folio store success before, then got dirtied again but zswap disabled, we won't invalidate the old duplicate entry in the zswap_store(). So later lru writeback may overwrite the new data in swapfile. Link: https://lkml.kernel.org/r/20240208023254.3873823-1-chengming.zhou@linux.dev Fixes: 42c06a0e8ebe ("mm: kill frontswap") Signed-off-by: Chengming Zhou <zhouchengming(a)bytedance.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Yosry Ahmed <yosryahmed(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/zswap.c b/mm/zswap.c index 36903d938c15..db4625af65fb 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1518,7 +1518,7 @@ bool zswap_store(struct folio *folio) if (folio_test_large(folio)) return false; - if (!zswap_enabled || !tree) + if (!tree) return false; /* @@ -1533,6 +1533,10 @@ bool zswap_store(struct folio *folio) zswap_invalidate_entry(tree, dupentry); } spin_unlock(&tree->lock); + + if (!zswap_enabled) + return false; + objcg = get_obj_cgroup_from_folio(folio); if (objcg && !obj_cgroup_may_zswap(objcg)) { memcg = get_mem_cgroup_from_objcg(objcg);

1 year, 8 months

4
4
0 0

[PATCH 6.7.y 0/6] Delay VERW - 6.7.y backport

by Pawan Gupta

This is the backport of recently upstreamed series that moves VERW execution to a later point in exit-to-user path. This is needed because in some cases it may be possible for data accessed after VERW executions may end into MDS affected CPU buffers. Moving VERW closer to ring transition reduces the attack surface. Patch 1/6 includes a minor fix that is queued for upstream: https://lore.kernel.org/lkml/170899674562.398.6398007479766564897.tip-bot2@… Patch 2/6 needed a conflict to be resolved for the hunk swapgs_restore_regs_and_return_to_usermode. Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- Pawan Gupta (5): x86/bugs: Add asm helpers for executing VERW x86/entry_64: Add VERW just before userspace transition x86/entry_32: Add VERW just before userspace transition x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key KVM/VMX: Move VERW closer to VMentry for MDS mitigation Sean Christopherson (1): KVM/VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH Documentation/arch/x86/mds.rst | 38 +++++++++++++++++++++++++----------- arch/x86/entry/entry.S | 23 ++++++++++++++++++++++ arch/x86/entry/entry_32.S | 3 +++ arch/x86/entry/entry_64.S | 11 +++++++++++ arch/x86/entry/entry_64_compat.S | 1 + arch/x86/include/asm/cpufeatures.h | 2 +- arch/x86/include/asm/entry-common.h | 1 - arch/x86/include/asm/nospec-branch.h | 25 ++++++++++++------------ arch/x86/kernel/cpu/bugs.c | 15 ++++++-------- arch/x86/kernel/nmi.c | 3 --- arch/x86/kvm/vmx/run_flags.h | 7 +++++-- arch/x86/kvm/vmx/vmenter.S | 9 ++++++--- arch/x86/kvm/vmx/vmx.c | 20 +++++++++++++++---- 13 files changed, 112 insertions(+), 46 deletions(-) --- base-commit: b631f5b445dc3379f67ff63a2e4c58f22d4975dc change-id: 20240226-delay-verw-backport-6-7-y-a2cb3f26bb90 Best regards, -- Thanks, Pawan

1 year, 8 months

3
12
0 0

[PATCH v4 0/4] usb: dwc3-am62: module removal and errata fixes

by Roger Quadros

Hi, This series fixes errors during module removal. It also implements PHY core voltage selection as per TI recommendation and workaround for Errata i2409 [1]. The workaround needs PHY2 region to be present in device node. The device tree patch will be sent later after the DT binding doc is merged. [1] - https://www.ti.com/lit/er/sprz487d/sprz487d.pdf Signed-off-by: Roger Quadros <rogerq(a)kernel.org> --- Changes in v4: - re-arranged patches into first 2 bug-fixes and added Cc stable for them - Added Acked-by - Link to v3: https://lore.kernel.org/r/20240214-for-v6-9-am62-usb-errata-3-0-v3-0-147ec5… --- Roger Quadros (4): usb: dwc3-am62: fix module unload/reload behavior usb: dwc3-am62: Disable wakeup at remove usb: dwc3-am62: Fix PHY core voltage selection usb: dwc3-am62: add workaround for Errata i2409 drivers/usb/dwc3/dwc3-am62.c | 42 ++++++++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 12 deletions(-) --- base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d change-id: 20240206-for-v6-9-am62-usb-errata-3-0-233024ea8e9d Best regards, -- Roger Quadros <rogerq(a)kernel.org>

1 year, 8 months

1
2
0 0

FAILED: patch "[PATCH] fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x b820de741ae48ccf50dd95e297889c286ff4f760 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024022602-unwrapped-haggler-daae@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: b820de741ae4 ("fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio") 9cf3516c29e6 ("fs: add IOCB flags related to passing back dio completions") f6c73a11133e ("fs.h: Add TRACE_IOCB_STRINGS for use in trace points") 1da8cf961bb1 ("Merge tag 'io_uring-6.0-2022-08-13' of git://git.kernel.dk/linux-block") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b820de741ae48ccf50dd95e297889c286ff4f760 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Thu, 15 Feb 2024 12:47:38 -0800 Subject: [PATCH] fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. Suggested-by: Jens Axboe <axboe(a)kernel.dk> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Avi Kivity <avi(a)scylladb.com> Cc: Sandeep Dhavale <dhavale(a)google.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: stable(a)vger.kernel.org Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org Signed-off-by: Christian Brauner <brauner(a)kernel.org> diff --git a/fs/aio.c b/fs/aio.c index bb2ff48991f3..da18dbcfcb22 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -593,6 +593,13 @@ void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel) struct kioctx *ctx = req->ki_ctx; unsigned long flags; + /* + * kiocb didn't come from aio or is neither a read nor a write, hence + * ignore it. + */ + if (!(iocb->ki_flags & IOCB_AIO_RW)) + return; + if (WARN_ON_ONCE(!list_empty(&req->ki_list))) return; @@ -1509,7 +1516,7 @@ static int aio_prep_rw(struct kiocb *req, const struct iocb *iocb) req->ki_complete = aio_complete_rw; req->private = NULL; req->ki_pos = iocb->aio_offset; - req->ki_flags = req->ki_filp->f_iocb_flags; + req->ki_flags = req->ki_filp->f_iocb_flags | IOCB_AIO_RW; if (iocb->aio_flags & IOCB_FLAG_RESFD) req->ki_flags |= IOCB_EVENTFD; if (iocb->aio_flags & IOCB_FLAG_IOPRIO) { diff --git a/include/linux/fs.h b/include/linux/fs.h index ed5966a70495..c2dcc98cb4c8 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -352,6 +352,8 @@ enum rw_hint { * unrelated IO (like cache flushing, new IO generation, etc). */ #define IOCB_DIO_CALLER_COMP (1 << 22) +/* kiocb is a read or write operation submitted by fs/aio.c. */ +#define IOCB_AIO_RW (1 << 23) /* for use in trace events */ #define TRACE_IOCB_STRINGS \

1 year, 8 months

3
2
0 0

FAILED: patch "[PATCH] mm/damon/reclaim: fix quota stauts loss due to online tunings" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 1b0ca4e4ff10a2c8402e2cf70132c683e1c772e4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024022643-scorn-filtrate-8677@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 1b0ca4e4ff10 ("mm/damon/reclaim: fix quota stauts loss due to online tunings") 66d9faec0745 ("mm/damon/reclaim: add a parameter called skip_anon for avoiding anonymous pages reclamation") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1b0ca4e4ff10a2c8402e2cf70132c683e1c772e4 Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Fri, 16 Feb 2024 11:40:24 -0800 Subject: [PATCH] mm/damon/reclaim: fix quota stauts loss due to online tunings Patch series "mm/damon: fix quota status loss due to online tunings". DAMON_RECLAIM and DAMON_LRU_SORT is not preserving internal quota status when applying new user parameters, and hence could cause temporal quota accuracy degradation. Fix it by preserving the status. This patch (of 2): For online parameters change, DAMON_RECLAIM creates new scheme based on latest values of the parameters and replaces the old scheme with the new one. When creating it, the internal status of the quota of the old scheme is not preserved. As a result, charging of the quota starts from zero after the online tuning. The data that collected to estimate the throughput of the scheme's action is also reset, and therefore the estimation should start from the scratch again. Because the throughput estimation is being used to convert the time quota to the effective size quota, this could result in temporal time quota inaccuracy. It would be recovered over time, though. In short, the quota accuracy could be temporarily degraded after online parameters update. Fix the problem by checking the case and copying the internal fields for the status. Link: https://lkml.kernel.org/r/20240216194025.9207-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240216194025.9207-2-sj@kernel.org Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [5.19+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c index ab974e477d2f..66e190f0374a 100644 --- a/mm/damon/reclaim.c +++ b/mm/damon/reclaim.c @@ -150,9 +150,20 @@ static struct damos *damon_reclaim_new_scheme(void) &damon_reclaim_wmarks); } +static void damon_reclaim_copy_quota_status(struct damos_quota *dst, + struct damos_quota *src) +{ + dst->total_charged_sz = src->total_charged_sz; + dst->total_charged_ns = src->total_charged_ns; + dst->charged_sz = src->charged_sz; + dst->charged_from = src->charged_from; + dst->charge_target_from = src->charge_target_from; + dst->charge_addr_from = src->charge_addr_from; +} + static int damon_reclaim_apply_parameters(void) { - struct damos *scheme; + struct damos *scheme, *old_scheme; struct damos_filter *filter; int err = 0; @@ -164,6 +175,11 @@ static int damon_reclaim_apply_parameters(void) scheme = damon_reclaim_new_scheme(); if (!scheme) return -ENOMEM; + if (!list_empty(&ctx->schemes)) { + damon_for_each_scheme(old_scheme, ctx) + damon_reclaim_copy_quota_status(&scheme->quota, + &old_scheme->quota); + } if (skip_anon) { filter = damos_new_filter(DAMOS_FILTER_TYPE_ANON, true); if (!filter) {

1 year, 8 months

3
2
0 0

[Regression] 5.4.269 fails to build due to security/apparmor/af_unix.c:583:17: error: too few arguments to function ‘unix_state_lock_nested’

by Philip Müller

Hi Greg, the issue might be due to this patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tre… 2024-02-23T15:39:05.6297767Z CC kernel/sys_ni.o 2024-02-23T15:39:05.7583048Z security/apparmor/af_unix.c: In function ‘unix_state_double_lock’: 2024-02-23T15:39:05.7586076Z security/apparmor/af_unix.c:583:17: error: too few arguments to function ‘unix_state_lock_nested’ 2024-02-23T15:39:05.7588374Z 583 | unix_state_lock_nested(sk2); 2024-02-23T15:39:05.7589913Z | ^~~~~~~~~~~~~~~~~~~~~~ 2024-02-23T15:39:05.7591564Z In file included from security/apparmor/include/af_unix.h:15, 2024-02-23T15:39:05.7593341Z from security/apparmor/af_unix.c:17: 2024-02-23T15:39:05.7594989Z ./include/net/af_unix.h:77:20: note: declared here 2024-02-23T15:39:05.7596733Z 77 | static inline void unix_state_lock_nested(struct sock *sk, 2024-02-23T15:39:05.7598516Z | ^~~~~~~~~~~~~~~~~~~~~~ 2024-02-23T15:39:05.7600862Z security/apparmor/af_unix.c:586:17: error: too few arguments to function ‘unix_state_lock_nested’ 2024-02-23T15:39:05.7603177Z 586 | unix_state_lock_nested(sk1); 2024-02-23T15:39:05.7605189Z | ^~~~~~~~~~~~~~~~~~~~~~ 2024-02-23T15:39:05.7606765Z ./include/net/af_unix.h:77:20: note: declared here 2024-02-23T15:39:05.7608497Z 77 | static inline void unix_state_lock_nested(struct sock *sk, 2024-02-23T15:39:05.7610208Z | ^~~~~~~~~~~~~~~~~~~~~~ 2024-02-23T15:39:05.8002385Z make[2]: *** [scripts/Makefile.build:262: security/apparmor/af_unix.o] Error 1 2024-02-23T15:39:05.8005077Z make[2]: *** Waiting for unfinished jobs.... 2024-02-23T15:39:05.8094726Z CC crypto/scatterwalk.o 2024-02-23T15:39:05.9082621Z CC [M] fs/btrfs/sysfs.o 2024-02-23T15:39:06.2502316Z CC kernel/nsproxy.o 2024-02-23T15:39:06.4094246Z make[1]: *** [scripts/Makefile.build:497: security/apparmor] Error 2 2024-02-23T15:39:06.4207119Z make: *** [Makefile:1750: security] Error 2 2024-02-23T15:39:06.4208636Z CC kernel/notifier.o 2024-02-23T15:39:06.4210296Z make: *** Waiting for unfinished jobs.... 2024-02-23T15:39:06.8604827Z CC crypto/proc.o -- Best, Philip

1 year, 8 months

2
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2024