- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

1 0

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

1 0

[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