- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] x86/kexec: Disable KCOV instrumentation after load_segments()
by Jinjie Ruan 12 Jun '26

12 Jun '26

From: Aleksandr Nogikh <nogikh(a)google.com> stable inclusion from stable-v6.12.93 commit 593d67032544b9271094fc9b43e437e017cb2b2f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14889 CVE: CVE-2026-43331 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 917e3ad3321e75ca0223d5ccf26ceda116aa51e1 ] The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ] Fixes: 0d345996e4cb ("x86/kernel: increase kcov coverage under arch/x86/kernel folder") Signed-off-by: Aleksandr Nogikh <nogikh(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260325154825.551191-1-nogikh@google.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/Makefile [context conflict.] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/Makefile | 14 ++++++++++++++ arch/x86/mm/Makefile | 2 ++ 2 files changed, 16 insertions(+) diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 341422135d9d..767bbcfd4dc3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -39,6 +39,20 @@ KMSAN_SANITIZE_nmi.o := n KCOV_INSTRUMENT_head$(BITS).o := n KCOV_INSTRUMENT_sev.o := n +# Disable KCOV to prevent crashes during kexec: load_segments() invalidates +# the GS base, which KCOV relies on for per-CPU data. +# +# As KCOV and KEXEC compatibility should be preserved (e.g. syzkaller is +# using it to collect crash dumps during kernel fuzzing), disabling +# KCOV for KEXEC kernels is not an option. Selectively disabling KCOV +# instrumentation for individual affected functions can be fragile, while +# adding more checks to KCOV would slow it down. +# +# As a compromise solution, disable KCOV instrumentation for the whole +# source code file. If its coverage is ever needed, other approaches +# should be considered. +KCOV_INSTRUMENT_machine_kexec_64.o := n + CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace obj-y += head_$(BITS).o diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index c9d9bee63d7d..d8f01c0f717b 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -5,6 +5,8 @@ KCOV_INSTRUMENT_mem_encrypt.o := n KCOV_INSTRUMENT_mem_encrypt_amd.o := n KCOV_INSTRUMENT_mem_encrypt_identity.o := n KCOV_INSTRUMENT_pgprot.o := n +# See the "Disable KCOV" comment in arch/x86/kernel/Makefile. +KCOV_INSTRUMENT_physaddr.o := n KASAN_SANITIZE_mem_encrypt.o := n KASAN_SANITIZE_mem_encrypt_amd.o := n -- 2.34.1

2 1

[PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..e3abbf0d9a4d 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,10 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time required to clear the cache once is approximately 100 + * nanoseconds. Based on a timeout period of 1 second, we set the + * number of timeout attempts to 1,000,000. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

2 1

[PATCH OLK-5.10] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index ea519c4fa7b3..3bb9c0dced6e 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1205,10 +1205,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index 2b00359e4825..bf6251fa5c3d 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1169,10 +1169,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH OLK-6.6] netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
by superdcc97＠163.com 12 Jun '26

12 Jun '26

From: Qi Tang <tpluszz77(a)gmail.com> stable inclusion from stable-v6.6.134 commit 2898080c054ea4d6ddfaaf21bbedbc229a9a8376 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14558 CVE: CVE-2026-43026 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 35177c6877134a21315f37d57a5577846225623e ] ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Qi Tang <tpluszz77(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_conntrack_netlink.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 67a0762915e3..90c32031bcf1 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -3571,6 +3571,12 @@ ctnetlink_alloc_expect(const struct nlattr * const cda[], struct nf_conn *ct, exp, nf_ct_l3num(ct)); if (err < 0) goto err_out; +#if IS_ENABLED(CONFIG_NF_NAT) + } else { + memset(&exp->saved_addr, 0, sizeof(exp->saved_addr)); + memset(&exp->saved_proto, 0, sizeof(exp->saved_proto)); + exp->dir = 0; +#endif } return exp; err_out: -- 2.43.0

2 1

[PATCH] [PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..dbceebb97ed4 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,9 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time for each loop operation is approximately 100ns to 500ns, + * and the ITS should clear the DT cache within 1,000,000 loops. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

1 0

[PATCH OLK-5.10] mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()
by Jinjiang Tu 11 Jun '26

11 Jun '26

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.136 commit 115a5266749dcde7fe4127e8623d19c752088f69 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14332 CVE: CVE-2026-31586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Dennis Zhou <dennis(a)kernel.org> Reviewed-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: David Hildenbrand <david(a)kernel.org> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Josef Bacik <josef(a)toxicpanda.com> Cc: JP Kobryn <inwardvessel(a)gmail.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Martin KaFai Lau <martin.lau(a)linux.dev> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: mm/backing-dev.c [Wupeng Ma: context conflicts] Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/backing-dev.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/backing-dev.c b/mm/backing-dev.c index bc406d62c617..ffc14382dc53 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -537,12 +537,13 @@ static void cgwb_release_workfn(struct work_struct *work) wb_shutdown(wb); css_put(wb->memcg_css); - css_put(wb->blkcg_css); - mutex_unlock(&wb->bdi->cgwb_release_mutex); /* triggers blkg destruction if no online users left */ blkcg_unpin_online(blkcg); + css_put(wb->blkcg_css); + mutex_unlock(&wb->bdi->cgwb_release_mutex); + fprop_local_destroy_percpu(&wb->memcg_completions); wb_exit(wb); call_rcu(&wb->rcu, cgwb_free_rcu); -- 2.43.0

2 1

[PATCH OLK-6.6 0/13] Update Share Pool
by Yin Tirui 11 Jun '26

11 Jun '26

Zhou Guanghui (1): mm: reserve address range for svsp fs/hugetlbfs/inode.c | 13 +++++ include/linux/ascend_vm.h | 69 ++++++++++++++++++++++++++ include/linux/share_pool.h | 11 ++-- include/uapi/asm-generic/mman-common.h | 1 + mm/Makefile | 1 + mm/ascend_vm.c | 21 ++++++++ mm/mmap.c | 15 ++++-- 7 files changed, 125 insertions(+), 6 deletions(-) create mode 100644 include/linux/ascend_vm.h create mode 100644 mm/ascend_vm.c -- 2.43.0

2 14

回复：[kernel] 驱动 Hht2dr 内核合入申请
by 刘俊豪 11 Jun '26

11 Jun '26

尊敬的 openEuler SIG 团队：您好！我司华澜微电子股份有限公司申请将 Hst2dr驱动（用于SAS HBA）加入 openEuler 内核，便于后续业务部署。烦请协助推进驱动合入相关事宜。如需要补充任何信息或材料，请随时与我联系。联系人：刘俊豪电子邮箱：junhao.liu(a)sage-micro.com.cn 感谢您的支持！华澜微电子股份有限公司 2026 年 06 月 11 日

1 0

[PATCH OLK-5.10] jbd2: limit checkpoint buffers scanned per j_list_lock hold during shrink
by Zizhi Wo 10 Jun '26

10 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9375 -------------------------------- When the shrinker walks a journal's checkpoint list via jbd2_journal_shrink_checkpoint_list(), it holds j_list_lock across each call to journal_shrink_one_cp_list() and only releases it when need_resched() or spin_needbreak() becomes true. journal_shrink_one_cp_list() charges the scan budget (nr_to_scan) only for buffers it actually frees. In JBD2_SHRINK_BUSY_SKIP mode, when metadata is heavily contended, most buffers are busy and cannot be freed, so "nr_to_scan" decreases slowly and the loop keeps walking the list for a long time. On large journals under heavy ext4 writeback, a single shrinker invocation can therefore hold j_list_lock long enough to starve other CPUs spinning for the same lock, triggering softlockups. Fix this by introducing a user-configurable per-hold budget that bounds the number of checkpoint buffers examined while j_list_lock is held, preventing the shrinker from walking the list for an unbounded time. The cap is disabled by default (value 0, preserving the previous behaviour) and can be enabled at runtime via /sys/module/jbd2/parameters/shrink_batch. Fixes: 82c2be921b1a ("jbd2,ext4: add a shrinker to release checkpointed buffers") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/jbd2/checkpoint.c | 48 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index 727f3505280c..ca7d60f6a858 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -19,10 +19,23 @@ #include <linux/jbd2.h> #include <linux/errno.h> #include <linux/slab.h> #include <linux/blkdev.h> #include <trace/events/jbd2.h> +#include <linux/moduleparam.h> + +/* + * Max number of checkpoint buffers to examine while holding j_list_lock + * in a single pass. + * + * Tunable at runtime via /sys/module/jbd2/parameters/shrink_batch. + * A value of 0 disables the per-hold cap (legacy behaviour). + */ +static unsigned int jbd2_shrink_batch; +module_param_named(shrink_batch, jbd2_shrink_batch, uint, 0644); +MODULE_PARM_DESC(shrink_batch, + "Max checkpoint buffers examined per j_list_lock hold during shrink (0 = unlimited)"); /* * Unlink a buffer from a transaction checkpoint list. * * Called with j_list_lock held. @@ -364,11 +377,12 @@ enum shrink_type {SHRINK_DESTROY, SHRINK_BUSY_STOP, SHRINK_BUSY_SKIP}; * * Called with j_list_lock held. */ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, enum shrink_type type, - bool *released) + bool *released, + unsigned long *scan_budget) { struct journal_head *last_jh; struct journal_head *next_jh = jh; unsigned long nr_freed = 0; int ret; @@ -383,10 +397,22 @@ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, next_jh = jh->b_cpnext; if (type == SHRINK_DESTROY) { ret = __jbd2_journal_remove_checkpoint(jh); } else { + /* + * Charge budget per examined buffer, not per freed one, + * so a run of busy buffers (the 'continue' path below, + * freeing nothing) still bounds how long one j_list_lock + * hold walks the checkpoint list. + */ + if (scan_budget) { + if (*scan_budget == 0) + break; + (*scan_budget)--; + } + ret = jbd2_journal_try_remove_checkpoint(jh); if (ret < 0) { if (type == SHRINK_BUSY_SKIP) continue; break; @@ -422,12 +448,23 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, bool __maybe_unused released; tid_t first_tid = 0, last_tid = 0, next_tid = 0; tid_t tid = 0; unsigned long nr_freed = 0; unsigned long freed; + unsigned long scan_budget; + unsigned int batch = READ_ONCE(jbd2_shrink_batch); again: + /* + * Reset the per-hold examination budget on every (re)acquire of + * j_list_lock: one hold examines at most `batch` buffers, decoupled + * from journal size, list length and busy ratio, so the lock hold + * stays short even when the whole list is busy and nothing is freed. + * batch == 0 means no cap, exactly the legacy behaviour. + */ + scan_budget = batch; + spin_lock(&journal->j_list_lock); if (!journal->j_checkpoint_transactions) { spin_unlock(&journal->j_list_lock); goto out; } @@ -452,13 +489,17 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, transaction = next_transaction; next_transaction = transaction->t_cpnext; tid = transaction->t_tid; freed = journal_shrink_one_cp_list(transaction->t_checkpoint_list, - SHRINK_BUSY_SKIP, &released); + SHRINK_BUSY_SKIP, &released, + batch ? &scan_budget : NULL); nr_freed += freed; (*nr_to_scan) -= min(*nr_to_scan, freed); + + if (batch && scan_budget == 0) + break; if (*nr_to_scan == 0) break; if (need_resched() || spin_needbreak(&journal->j_list_lock)) break; } while (transaction != last_transaction); @@ -505,12 +546,13 @@ void __jbd2_journal_clean_checkpoint_list(journal_t *journal, bool destroy) last_transaction = transaction->t_cpprev; next_transaction = transaction; do { transaction = next_transaction; next_transaction = transaction->t_cpnext; + /* destroy/clean path: clear everything, no scan budget */ journal_shrink_one_cp_list(transaction->t_checkpoint_list, - type, &released); + type, &released, NULL); /* * This function only frees up some memory if possible so we * dont have an obligation to finish processing. Bail out if * preemption requested: */ -- 2.52.0

2 1