- Kernel - mailweb.openeuler.org

[PATCH v5 0/4] arm64/riscv: Add support for crashkernel CMA reservation
by Jinjie Ruan 12 Feb '26

12 Feb '26

Exclude crash kernel memory in crash core to avoid duplication. Also move the size calculation (and the realloc if needed) into crash core. And add support for crashkernel CMA reservation for arm64 and riscv. Changes in v5: - Fix the kernel test robot build warnings. - Sort crash memory ranges before preparing elfcorehdr for powerpc - Link to v4: https://lore.kernel.org/all/20260209095931.2813152-1-ruanjinjie@huawei.com/ Changes in v4: - Move the size calculation (and the realloc if needed) into the generic crash. - Link to v3: https://lore.kernel.org/all/20260204093728.1447527-1-ruanjinjie@huawei.com/ Changs in v3: - Exclude crash kernel memory in crash core as Mike suggested. - Add acked-by. Jinjie Ruan (3): crash: Exclude crash kernel memory in crash core arm64: kexec: Add support for crashkernel CMA reservation riscv: kexec: Add support for crashkernel CMA reservation Sourabh Jain (1): powerpc/crash: sort crash memory ranges before preparing elfcorehdr .../admin-guide/kernel-parameters.txt | 16 +-- arch/arm64/include/asm/kexec.h | 9 +- arch/arm64/kernel/machine_kexec_file.c | 43 +++----- arch/arm64/mm/init.c | 5 +- arch/loongarch/include/asm/kexec.h | 9 +- arch/loongarch/kernel/machine_kexec_file.c | 41 +++---- arch/powerpc/include/asm/kexec.h | 13 +++ arch/powerpc/include/asm/kexec_ranges.h | 1 - arch/powerpc/kexec/crash.c | 67 ++++++----- arch/powerpc/kexec/file_load_64.c | 17 +-- arch/powerpc/kexec/ranges.c | 103 +---------------- arch/riscv/include/asm/kexec.h | 9 +- arch/riscv/kernel/machine_kexec_file.c | 39 +++---- arch/riscv/mm/init.c | 5 +- arch/x86/include/asm/kexec.h | 9 ++ arch/x86/kernel/crash.c | 104 ++---------------- include/linux/crash_core.h | 75 ++++++++++++- kernel/crash_core.c | 85 ++++++++++++-- 18 files changed, 314 insertions(+), 336 deletions(-) -- 2.34.1

1 4

[PATCH OLK-6.6] dm: use bio_clone_blkg_association
by Zhihao Cheng 12 Feb '26

12 Feb '26

From: Mikulas Patocka <mpatocka(a)redhat.com> mainline inclusion from mainline-v7.0-rc1 commit 2df8b310bcfe76827fd71092f58a2493ee6590b0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13467 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The origin bio carries blk-cgroup information which could be set from foreground(task_css(css) - wbc->wb->blkcg_css), so the blkcg won't control buffer io since commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone"). The synchronous io is still under control by blkcg, because 'bio->bi_blkg' is set by io submitting task which has been added into 'cgroup.procs'. Fix it by using bio_clone_blkg_association when submitting a cloned bio. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220985 Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Reported-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Tested-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- drivers/md/dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 96f050891ec0..670460ade280 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1365,6 +1365,8 @@ void dm_submit_bio_remap(struct bio *clone, struct bio *tgt_clone) if (!tgt_clone) tgt_clone = clone; + bio_clone_blkg_association(tgt_clone, io->orig_bio); + /* * Account io->origin_bio to DM dev on behalf of target * that took ownership of IO with DM_MAPIO_SUBMITTED. -- 2.52.0

2 1

[PATCH OLK-6.6] gic: Add hip09 support for HISILICON_ERRATUM_165010801
by Zeng Heng 12 Feb '26

12 Feb '26

From: Yifan Wu <wuyifan50(a)huawei.com> driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/7023 ---------------------------------------------------------------------- Add hip09 support for HISILICON_ERRATUM_165010801 Fixes: f0f9be237c22 ("gic: increase the arch_timer priority to avoid hardlockup") Signed-off-by: Yifan Wu <wuyifan50(a)huawei.com> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/Kconfig | 11 ++++++----- drivers/clocksource/arm_arch_timer.c | 5 +++++ 2 files changed, 11 insertions(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index ef8c524a296d..2a4a729ef8f7 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1309,11 +1309,12 @@ config HISILICON_ERRATUM_165010801 depends on ARCH_HISI default y help - On HIP12, when GIC receives multiple interrupts of the same priority and - different types, the interrupts are selected in the following sequence: - SPI > LPI > SGI > PPI. This scheduling rule may cause PPI starvation. - To prevent starvation from triggering system watchdog hardlockup, the - interrupt priority is explicitly increased in the arch_timer driver. + On HIP09/12 hardware, observations indicate that the GIC's handling of + equal-priority interrupts across different interrupt types may not always + provide balanced servicing. In some cases, this could result in prolonged + service delays for particular interrupt types, creating conditions where + system watchdog hardlockup detection might be triggered. The arch_timer + driver addresses this by proactively increasing affected interrupt priorities. config QCOM_FALKOR_ERRATUM_1003 bool "Falkor E1003: Incorrect translation due to ASID change" diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 095238032ac0..7ffca7cc5c53 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -369,6 +369,11 @@ static struct ate_acpi_oem_info hisi_161010101_oem_info[] = { #ifdef CONFIG_HISILICON_ERRATUM_165010801 static struct ate_acpi_oem_info hisi_165010801_oem_info[] = { + { + .oem_id = "HISI ", + .oem_table_id = "HIP09 ", + .oem_revision = 0, + }, { .oem_id = "HISI ", .oem_table_id = "HIP12 ", -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] irqchip/gic-v3-its: Avoid truncating memory addresses
by Jinjie Ruan 12 Feb '26

12 Feb '26

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v6.6.122 commit 1b323391560354d8c515de8658b057a1daa82adb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13618 CVE: CVE-2026-23085 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8d76a7d89c12d08382b66e2f21f20d0627d14859 upstream. On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260119201603.2713066-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/irqchip/irq-gic-v3-its.c [ Conflict because 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") not merged. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 65306a1ed3dc..750fcb25574a 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -459,7 +459,7 @@ static struct its_collection *its_build_mapd_cmd(struct its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long itt_addr; + phys_addr_t itt_addr; u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); @@ -629,7 +629,7 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long vpt_addr; + phys_addr_t vpt_addr; u64 target; vpt_addr = virt_to_phys(page_address(desc->its_vmapp_cmd.vpe->vpt_page)); @@ -2023,10 +2023,10 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser, baser->psz = psz; tmp = indirect ? GITS_LVL1_ENTRY_SIZE : esz; - pr_info("ITS@%pa: allocated %d %s @%lx (%s, esz %d, psz %dK, shr %d)\n", + pr_info("ITS@%pa: allocated %d %s @%llx (%s, esz %d, psz %dK, shr %d)\n", &its->phys_base, (int)(PAGE_ORDER_TO_SIZE(order) / (int)tmp), its_base_type_string[type], - (unsigned long)virt_to_phys(base), + (u64)virt_to_phys(base), indirect ? "indirect" : "flat", (int)esz, psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT); -- 2.34.1

2 1

[PATCH OLK-6.6] tracing: Fix soft lockup when lseeking trace file
by Tengda Wu 12 Feb '26

12 Feb '26

From: Tengda Wu <wutengda(a)huaweicloud.com> maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8522 Reference: https://lore.kernel.org/all/20260209093101.1623454-1-wutengda@huaweicloud.c… -------------------------------- A soft lockup may occur when accessing trace file via lseek while tracing is active and a large offset is provided. The call trace is shown below: watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [poc:141] CPU: 3 UID: 0 PID: 141 Comm: poc Not tainted 6.19.0 #1 PREEMPT(none) Call Trace: ring_buffer_iter_peek peek_next_entry __find_next_entry trace_find_next_entry_inc s_next traverse.part.0 seq_lseek tracing_lseek __x64_sys_lseek do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is that the lseek implementation for trace files is based on seq_lseek, which contains a loop that repeatedly calls show() and next() functions until the position reaches the target offset. Since no scheduling point is set within this loop, a large offset can cause the CPU to be stuck in the loop for an extended period, triggering the soft lockup detector. Fixed by adding cond_resched() in s_next(). Fixes: bc0c38d139ec ("ftrace: latency tracer infrastructure") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b0751e52d40e..95ede691941c 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4037,6 +4037,8 @@ static void *s_next(struct seq_file *m, void *v, loff_t *pos) iter->pos = *pos; + cond_resched(); + return ent; } -- 2.34.1

2 1

[PATCH OLK-5.10] tracing: Fix soft lockup when lseeking trace file
by Tengda Wu 12 Feb '26

12 Feb '26

From: Tengda Wu <wutengda(a)huaweicloud.com> maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8522 Reference: https://lore.kernel.org/all/20260209093101.1623454-1-wutengda@huaweicloud.c… -------------------------------- A soft lockup may occur when accessing trace file via lseek while tracing is active and a large offset is provided. The call trace is shown below: watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [poc:141] CPU: 3 UID: 0 PID: 141 Comm: poc Not tainted 6.19.0 #1 PREEMPT(none) Call Trace: ring_buffer_iter_peek peek_next_entry __find_next_entry trace_find_next_entry_inc s_next traverse.part.0 seq_lseek tracing_lseek __x64_sys_lseek do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is that the lseek implementation for trace files is based on seq_lseek, which contains a loop that repeatedly calls show() and next() functions until the position reaches the target offset. Since no scheduling point is set within this loop, a large offset can cause the CPU to be stuck in the loop for an extended period, triggering the soft lockup detector. Fixed by adding cond_resched() in s_next(). Fixes: bc0c38d139ec ("ftrace: latency tracer infrastructure") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 6c5a503987e7..631a9d263e57 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -3678,6 +3678,8 @@ static void *s_next(struct seq_file *m, void *v, loff_t *pos) iter->pos = *pos; + cond_resched(); + return ent; } -- 2.34.1

2 1

[PATCH OLK-5.10] uacce: fix cdev handling in the cleanup path
by Wang Tao 11 Feb '26

11 Feb '26

From: Wenkai Lin <linwenkai6(a)hisilicon.com> mainline inclusion from mainline-v6.19-rc7 commit a3bece3678f6c88db1f44c602b2a63e84b4040ac category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13629 CVE: CVE-2026-23096 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove. Fixes: 015d239ac014 ("uacce: add uacce driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wenkai Lin <linwenkai6(a)hisilicon.com> Signed-off-by: Chenghai Huang <huangchenghai2(a)huawei.com> Acked-by: Zhangfei Gao <zhangfei.gao(a)linaro.org> Link: https://patch.msgid.link/20251202061256.4158641-2-huangchenghai2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- drivers/misc/uacce/uacce.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c index 687b7fad9a29..b50ddd46fd72 100644 --- a/drivers/misc/uacce/uacce.c +++ b/drivers/misc/uacce/uacce.c @@ -982,6 +982,8 @@ EXPORT_SYMBOL_GPL(uacce_alloc); */ int uacce_register(struct uacce_device *uacce) { + int ret; + if (!uacce) return -ENODEV; @@ -992,7 +994,11 @@ int uacce_register(struct uacce_device *uacce) uacce->cdev->ops = &uacce_fops; uacce->cdev->owner = THIS_MODULE; - return cdev_device_add(uacce->cdev, &uacce->dev); + ret = cdev_device_add(uacce->cdev, &uacce->dev); + if (ret) + uacce->cdev = NULL; + + return ret; } EXPORT_SYMBOL_GPL(uacce_register); -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] Revert hibmc patches to fix null-ptr-deref
by Tengda Wu 11 Feb '26

11 Feb '26

This patch series is going to revert pull requests: !19950 and !20738. Tengda Wu (2): Revert "!20738 drm/hisilicon: Using the to_hibmc_drm_private to convert" Revert "!19950 【OLK-5.10】 Drivers GPU Patches from 6.6" drivers/gpu/drm/drm_connector.c | 9 - drivers/gpu/drm/drm_internal.h | 2 - drivers/gpu/drm/drm_probe_helper.c | 29 -- drivers/gpu/drm/drm_sysfs.c | 17 +- drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 - drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 +- drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c | 167 ------- drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h | 73 --- .../gpu/drm/hisilicon/hibmc/dp/dp_config.h | 21 - drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c | 338 -------------- drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h | 74 ---- drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c | 415 ------------------ drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h | 140 ------ .../gpu/drm/hisilicon/hibmc/dp/dp_serdes.c | 59 --- .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 24 +- .../drm/hisilicon/hibmc/hibmc_drm_debugfs.c | 149 ------- .../gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c | 257 ----------- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 176 +++----- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 35 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 48 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 64 +-- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 +- include/drm/drm_probe_helper.h | 3 - 23 files changed, 126 insertions(+), 1988 deletions(-) delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_config.h delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_serdes.c delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_debugfs.c delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c -- 2.34.1

2 3

[PATCH OLK-6.6] net: usb: asix: validate PHY address before use
by Wupeng Ma 11 Feb '26

11 Feb '26

From: Deepanshu Kartikey <kartikey406(a)gmail.com> stable inclusion from stable-v6.6.120 commit 38722e69ee64dbb020028c93898d25d6f4c0e0b2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8372 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a1e077a3f76eea0dc671ed6792e7d543946227e8 ] The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76 Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c. Reported-by: syzbot+3d43c9066a5b54902232(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d43c9066a5b54902232 Tested-by: syzbot+3d43c9066a5b54902232(a)syzkaller.appspotmail.com Fixes: 7e88b11a862a ("net: usb: asix: refactor asix_read_phy_addr() and handle errors on return") Link: https://lore.kernel.org/all/20251217085057.270704-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Link: https://patch.msgid.link/20251218011156.276824-1-kartikey406@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yuan can <yuancan(a)huawei.com> Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- drivers/net/usb/asix_common.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c index 7fd763917ae2c..6ab3486072cb0 100644 --- a/drivers/net/usb/asix_common.c +++ b/drivers/net/usb/asix_common.c @@ -335,6 +335,11 @@ int asix_read_phy_addr(struct usbnet *dev, bool internal) offset = (internal ? 1 : 0); ret = buf[offset]; + if (ret >= PHY_MAX_ADDR) { + netdev_err(dev->net, "invalid PHY address: %d\n", ret); + return -ENODEV; + } + netdev_dbg(dev->net, "%s PHY address 0x%x\n", internal ? "internal" : "external", ret); -- 2.43.0

2 1

[PATCH OLK-6.6] smc91x: fix broken irq-context in PREEMPT_RT
by Wupeng Ma 11 Feb '26

11 Feb '26

From: Yeoreum Yun <yeoreum.yun(a)arm.com> stable inclusion from stable-v6.6.120 commit ef277ae121b3249c99994652210a326b52d527b0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8372 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6402078bd9d1ed46e79465e1faaa42e3458f8a33 ] When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC: [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20 This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero. To address this issue, replace smc_special_trylock() with spin_trylock_irqsave(). Fixes: 342a93247e08 ("locking/spinlock: Provide RT variant header: <linux/spinlock_rt.h>") Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251217085115.1730036-1-yeoreum.yun@arm.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yuan can <yuancan(a)huawei.com> Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- drivers/net/ethernet/smsc/smc91x.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c index 032eccf8eb428..7c2fdd02f1d34 100644 --- a/drivers/net/ethernet/smsc/smc91x.c +++ b/drivers/net/ethernet/smsc/smc91x.c @@ -515,15 +515,7 @@ static inline void smc_rcv(struct net_device *dev) * any other concurrent access and C would always interrupt B. But life * isn't that easy in a SMP world... */ -#define smc_special_trylock(lock, flags) \ -({ \ - int __ret; \ - local_irq_save(flags); \ - __ret = spin_trylock(lock); \ - if (!__ret) \ - local_irq_restore(flags); \ - __ret; \ -}) +#define smc_special_trylock(lock, flags) spin_trylock_irqsave(lock, flags) #define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags) #define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags) #else -- 2.43.0

2 1