- Kernel - mailweb.openeuler.org

[PATCH v4 openEuler-26.09 00/13] Introduce dmem cgroup
by Liu Kai 03 Mar '26

03 Mar '26

Introduce dmem cgroup Alexander Pavlenko (p00812954) (1): xsched/dmem: set max region size of xsched dmem root group to physical XPU memory size Chen Ridong (3): cgroup/dmem: fix NULL pointer dereference when setting max cgroup/dmem: avoid rcu warning when unregister region cgroup/dmem: avoid pool UAF Friedrich Vock (1): cgroup/dmem: Don't open-code css_for_each_descendant_pre Geert Uytterhoeven (1): cgroup/rdma: Drop bogus PAGE_COUNTER select Jiapeng Chong (1): kernel/cgroup: Remove the unused variable climit Maarten Lankhorst (2): mm/page_counter: move calculating protection values to page_counter kernel/cgroup: Add "dmem" memory accounting cgroup Maxime Ripard (3): cgroup/dmem: Select PAGE_COUNTER cgroup/dmem: Fix parameters documentation doc/cgroup: Fix title underline length Roman Gushchin (1): mm: page_counters: put page_counter_calculate_protection() under CONFIG_MEMCG Documentation/admin-guide/cgroup-v2.rst | 58 +- Documentation/core-api/cgroup.rst | 9 + Documentation/core-api/index.rst | 1 + Documentation/gpu/drm-compute.rst | 54 ++ include/linux/cgroup_dmem.h | 66 ++ include/linux/cgroup_subsys.h | 4 + include/linux/page_counter.h | 10 + init/Kconfig | 10 + kernel/cgroup/Makefile | 1 + kernel/cgroup/cgroup.c | 2 +- kernel/cgroup/dmem.c | 888 ++++++++++++++++++++++++ mm/memcontrol.c | 154 +--- mm/page_counter.c | 175 +++++ 13 files changed, 1273 insertions(+), 159 deletions(-) create mode 100644 Documentation/core-api/cgroup.rst create mode 100644 Documentation/gpu/drm-compute.rst create mode 100644 include/linux/cgroup_dmem.h create mode 100644 kernel/cgroup/dmem.c -- 2.34.1

2 14

openEuler Kernel SIG双周例会
by openEuler conference 03 Mar '26

03 Mar '26

您好！ Kernel 邀请您参加 2026-03-06 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议发起人： LiaoTao_Wave 会议内容： 1. 进展update 2. 议题征集中，新增议题可直接填报至会议纪要看板会议链接：https://meeting.huaweicloud.com:36443/#/j/963264350 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! Kernel invites you to attend the WeLink conference(auto recording) will be held at 2026-03-06 14:00 The subject of the conference is openEuler Kernel SIG双周例会 The sponsor of the conference is LiaoTao_Wave Summary: 1. 进展update 2. 议题征集中，新增议题可直接填报至会议纪要看板 You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/963264350 Add topics at https://etherpad.openeuler.org/p/Kernel-meetings More information: https://www.openeuler.org/en/

1 0

[PATCH OLK-6.6] PCI: Fix NVMe link speed downgrade to 2.5GT/s during hotplug
by Hongtao Zhang 03 Mar '26

03 Mar '26

From: Jinhui Guo <guojinhui.liam(a)bytedance.com> maillist inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13837 Reference: https://lore.kernel.org/all/20241107143758.12643-1-guojinhui.liam@bytedance… ------------------------------------------- During extreme hotplug stress tests (e.g., NVMe insertions 50 times), the link speed is permanently downgraded to 2.5 GT/s. "Card present" is reported twice via external interrupts due to a slight tremor when the NVMe device is plugged in. The failure of the link activation for the first time leads to the link speed of the root port being mistakenly downgraded to 2.5GT/s by the ASMedia workaround. If the link subsequently trains successfully at 2.5GT/s, the device gets trapped at Gen1 speed because the recovery logic only applies to ASMedia chips. Upstream community addressed this by relying on the newly introduced pci/bwctrl subsystem (Commit de9a6c8d5dbf), which is not present in stable kernels like 6.6. Backporting the mainline fix would require pulling in massive architectural changes and risking system stability. This patch adopts the RFC approach to avoid wrongly setting the link speed to 2.5GT/s by moving the whitelist check to the very beginning. Only allow the specific ASMedia PCIe switches to perform link retrain. Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures") Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/pci/quirks.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index a2a2bde69a026..fbdd54cc81c71 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -94,7 +94,8 @@ int pcie_failed_link_retrain(struct pci_dev *dev) int ret = -ENOTTY; if (!pci_is_pcie(dev) || !pcie_downstream_port(dev) || - !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting) + !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting || + !pci_match_id(ids, dev)) return ret; pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2); @@ -122,8 +123,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev) } if ((lnksta & PCI_EXP_LNKSTA_DLLLA) && - (lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT && - pci_match_id(ids, dev)) { + (lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT) { u32 lnkcap; pci_info(dev, "removing 2.5GT/s downstream link speed restriction\n"); -- 2.43.0

2 1

[PATCH v2 OLK-6.6 0/8] arm64: Add memory poison recovery support for various paths
by Wupeng Ma 02 Mar '26

02 Mar '26

This series enhances the arm64 kernel's ability to recover from memory poison (hardware memory errors) encountered during common I/O and data copy operations. The work extends the existing RAS error handling framework to gracefully handle poison in scenarios that previously could lead to kernel panics or silent data corruption. Memory errors are increasingly common in large-scale deployments; recovering from them where possible improves system reliability and availability. The patches implement recovery in key paths such as copy_{from/to}_user, iov_iter, __kernel_read, and shmem_file_read_iter, ensuring that when poison is consumed, the kernel can either complete the operation safely (by returning an error) or deliver the appropriate signal to the affected user process. Additionally, the series refines the SEA (Synchronous External Abort) handling path: it moves siaddr extraction earlier for accurate signal info, adds RAS logging for better diagnostics, and ensures a SIGBUS is sent to user tasks when APEI claims fail. The series has been tested on ARM64 platforms with RAS capabilities, using error injection to verify that poison is correctly handled and that appropriate errors or signals are delivered. Feedback and review are appreciated. Changelog since v1: - use correct issue Linus Torvalds (1): iov_iter: get rid of 'copy_mc' flag Wupeng Ma (7): arm64: mm: support recovery from copy_{from/to}_user_page() iov_iter: add mc support for copy_page_to_iter arm64: fs: support poison recovery from __kernel_read() arm64: mm: shmem: support poison recovery from shmem_file_read_iter() arm64: move getting valid siaddr to the top of do_sea arm64: add ras log during do_sea arm64: send sig fault for user task when apei_claim_sea fails arch/arm64/include/asm/cacheflush.h | 7 +++++ arch/arm64/kernel/acpi.c | 2 ++ arch/arm64/mm/extable.c | 5 +++- arch/arm64/mm/fault.c | 46 ++++++++++++++++++++++------- arch/arm64/mm/flush.c | 11 +++++++ fs/coredump.c | 45 ++++++++++++++++++++++++++-- include/asm-generic/cacheflush.h | 24 +++++++++++++++ lib/iov_iter.c | 16 ++++++++-- mm/filemap.c | 3 ++ mm/memory.c | 15 +++++++--- mm/shmem.c | 4 +++ 11 files changed, 158 insertions(+), 20 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6 0/8] arm64: Add memory poison recovery support for various paths
by Wupeng Ma 02 Mar '26

02 Mar '26

This series enhances the arm64 kernel's ability to recover from memory poison (hardware memory errors) encountered during common I/O and data copy operations. The work extends the existing RAS error handling framework to gracefully handle poison in scenarios that previously could lead to kernel panics or silent data corruption. Memory errors are increasingly common in large-scale deployments; recovering from them where possible improves system reliability and availability. The patches implement recovery in key paths such as copy_{from/to}_user, iov_iter, __kernel_read, and shmem_file_read_iter, ensuring that when poison is consumed, the kernel can either complete the operation safely (by returning an error) or deliver the appropriate signal to the affected user process. Additionally, the series refines the SEA (Synchronous External Abort) handling path: it moves siaddr extraction earlier for accurate signal info, adds RAS logging for better diagnostics, and ensures a SIGBUS is sent to user tasks when APEI claims fail. The series has been tested on ARM64 platforms with RAS capabilities, using error injection to verify that poison is correctly handled and that appropriate errors or signals are delivered. Feedback and review are appreciated. Linus Torvalds (1): iov_iter: get rid of 'copy_mc' flag Wupeng Ma (7): arm64: mm: support recovery from copy_{from/to}_user_page() iov_iter: add mc support for copy_page_to_iter arm64: fs: support poison recovery from __kernel_read() arm64: mm: shmem: support poison recovery from shmem_file_read_iter() arm64: move getting valid siaddr to the top of do_sea arm64: add ras log during do_sea arm64: send sig fault for user task when apei_claim_sea fails arch/arm64/include/asm/cacheflush.h | 7 +++++ arch/arm64/kernel/acpi.c | 2 ++ arch/arm64/mm/extable.c | 5 +++- arch/arm64/mm/fault.c | 46 ++++++++++++++++++++++------- arch/arm64/mm/flush.c | 11 +++++++ fs/coredump.c | 45 ++++++++++++++++++++++++++-- include/asm-generic/cacheflush.h | 24 +++++++++++++++ lib/iov_iter.c | 16 ++++++++-- mm/filemap.c | 3 ++ mm/memory.c | 15 +++++++--- mm/shmem.c | 4 +++ 11 files changed, 158 insertions(+), 20 deletions(-) -- 2.43.0

2 9

[PATCH openEuler-1.0-LTS] PCI: Fix pci_slot_trylock() error handling
by Ziming Du 02 Mar '26

02 Mar '26

From: Jinhui Guo <guojinhui.liam(a)bytedance.com> mainline inclusion from mainline-v7.0-rc1 commit 9368d1ee62829b08aa31836b3ca003803caf0b72 category: bugfix bugzilla: 190823 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com Signed-off-by: Ziming Du <duziming2(a)huawei.com> --- drivers/pci/pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b93605616d4e4..fbef3c37f37fa 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5144,10 +5144,8 @@ static int pci_slot_trylock(struct pci_slot *slot) if (!dev->slot || dev->slot != slot) continue; if (dev->subordinate) { - if (!pci_bus_trylock(dev->subordinate)) { - pci_dev_unlock(dev); + if (!pci_bus_trylock(dev->subordinate)) goto unlock; - } } else if (!pci_dev_trylock(dev)) goto unlock; } -- 2.43.0

2 1

[PATCH OLK-6.6 v2] KVM: arm64: Fix softirq masking in FPSIMD register saving sequence
by Yipeng Zou 02 Mar '26

02 Mar '26

From: Will Deacon <will(a)kernel.org> stable inclusion from stable-v6.6.111 commit 250b6e009ff97f69411aa109116ac720d54f45ec category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8596 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Stable commit 28b82be094e2 ("KVM: arm64: Fix kernel BUG() due to bad backport of FPSIMD/SVE/SME fix") fixed a kernel BUG() caused by a bad backport of upstream commit fbc7e61195e2 ("KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state") by ensuring that softirqs are disabled/enabled across the fpsimd register save operation. Unfortunately, although this fixes the original issue, it can now lead to deadlock when re-enabling softirqs causes pending softirqs to be handled with locks already held: | BUG: spinlock recursion on CPU#7, CPU 3/KVM/57616 | lock: 0xffff3045ef850240, .magic: dead4ead, .owner: CPU 3/KVM/57616, .owner_cpu: 7 | CPU: 7 PID: 57616 Comm: CPU 3/KVM Tainted: G O 6.1.152 #1 | Hardware name: SoftIron SoftIron Platform Mainboard/SoftIron Platform Mainboard, BIOS 1.31 May 11 2023 | Call trace: | dump_backtrace+0xe4/0x110 | show_stack+0x20/0x30 | dump_stack_lvl+0x6c/0x88 | dump_stack+0x18/0x34 | spin_dump+0x98/0xac | do_raw_spin_lock+0x70/0x128 | _raw_spin_lock+0x18/0x28 | raw_spin_rq_lock_nested+0x18/0x28 | update_blocked_averages+0x70/0x550 | run_rebalance_domains+0x50/0x70 | handle_softirqs+0x198/0x328 | __do_softirq+0x1c/0x28 | ____do_softirq+0x18/0x28 | call_on_irq_stack+0x30/0x48 | do_softirq_own_stack+0x24/0x30 | do_softirq+0x74/0x90 | __local_bh_enable_ip+0x64/0x80 | fpsimd_save_and_flush_cpu_state+0x5c/0x68 | kvm_arch_vcpu_put_fp+0x4c/0x88 | kvm_arch_vcpu_put+0x28/0x88 | kvm_sched_out+0x38/0x58 | __schedule+0x55c/0x6c8 | schedule+0x60/0xa8 Take a tiny step towards the upstream fix in 9b19700e623f ("arm64: fpsimd: Drop unneeded 'busy' flag") by additionally disabling hardirqs while saving the fpsimd registers. Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Lee Jones <lee(a)kernel.org> Cc: Sasha Levin <sashal(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> # 6.6.y Fixes: 208d4f745a52 ("KVM: arm64: Fix kernel BUG() due to bad backport of FPSIMD/SVE/SME fix") Reported-by: Kenneth Van Alstyne <kvanals(a)kvanals.org> Link: https://lore.kernel.org/r/010001999bae0958-4d80d25d-8dda-4006-a6b9-798f3e77… Signed-off-by: Will Deacon <will(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- arch/arm64/kernel/fpsimd.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 75344016b14c..9da29ae8a045 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1870,13 +1870,17 @@ static void fpsimd_flush_cpu_state(void) */ void fpsimd_save_and_flush_cpu_state(void) { + unsigned long flags; + if (!system_supports_fpsimd()) return; WARN_ON(preemptible()); - get_cpu_fpsimd_context(); + local_irq_save(flags); + __get_cpu_fpsimd_context(); fpsimd_save(); fpsimd_flush_cpu_state(); - put_cpu_fpsimd_context(); + __put_cpu_fpsimd_context(); + local_irq_restore(flags); } #ifdef CONFIG_KERNEL_MODE_NEON -- 2.34.1

2 1

[PATCH OLK-6.6] KVM: arm64: Fix softirq masking in FPSIMD register saving sequence
by Yipeng Zou 02 Mar '26

02 Mar '26

From: Will Deacon <will(a)kernel.org> stable inclusion from stable-v6.6.111 commit 250b6e009ff97f69411aa109116ac720d54f45ec category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Stable commit 28b82be094e2 ("KVM: arm64: Fix kernel BUG() due to bad backport of FPSIMD/SVE/SME fix") fixed a kernel BUG() caused by a bad backport of upstream commit fbc7e61195e2 ("KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state") by ensuring that softirqs are disabled/enabled across the fpsimd register save operation. Unfortunately, although this fixes the original issue, it can now lead to deadlock when re-enabling softirqs causes pending softirqs to be handled with locks already held: | BUG: spinlock recursion on CPU#7, CPU 3/KVM/57616 | lock: 0xffff3045ef850240, .magic: dead4ead, .owner: CPU 3/KVM/57616, .owner_cpu: 7 | CPU: 7 PID: 57616 Comm: CPU 3/KVM Tainted: G O 6.1.152 #1 | Hardware name: SoftIron SoftIron Platform Mainboard/SoftIron Platform Mainboard, BIOS 1.31 May 11 2023 | Call trace: | dump_backtrace+0xe4/0x110 | show_stack+0x20/0x30 | dump_stack_lvl+0x6c/0x88 | dump_stack+0x18/0x34 | spin_dump+0x98/0xac | do_raw_spin_lock+0x70/0x128 | _raw_spin_lock+0x18/0x28 | raw_spin_rq_lock_nested+0x18/0x28 | update_blocked_averages+0x70/0x550 | run_rebalance_domains+0x50/0x70 | handle_softirqs+0x198/0x328 | __do_softirq+0x1c/0x28 | ____do_softirq+0x18/0x28 | call_on_irq_stack+0x30/0x48 | do_softirq_own_stack+0x24/0x30 | do_softirq+0x74/0x90 | __local_bh_enable_ip+0x64/0x80 | fpsimd_save_and_flush_cpu_state+0x5c/0x68 | kvm_arch_vcpu_put_fp+0x4c/0x88 | kvm_arch_vcpu_put+0x28/0x88 | kvm_sched_out+0x38/0x58 | __schedule+0x55c/0x6c8 | schedule+0x60/0xa8 Take a tiny step towards the upstream fix in 9b19700e623f ("arm64: fpsimd: Drop unneeded 'busy' flag") by additionally disabling hardirqs while saving the fpsimd registers. Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Lee Jones <lee(a)kernel.org> Cc: Sasha Levin <sashal(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> # 6.6.y Fixes: 208d4f745a52 ("KVM: arm64: Fix kernel BUG() due to bad backport of FPSIMD/SVE/SME fix") Reported-by: Kenneth Van Alstyne <kvanals(a)kvanals.org> Link: https://lore.kernel.org/r/010001999bae0958-4d80d25d-8dda-4006-a6b9-798f3e77… Signed-off-by: Will Deacon <will(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- arch/arm64/kernel/fpsimd.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 75344016b14c..9da29ae8a045 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1870,13 +1870,17 @@ static void fpsimd_flush_cpu_state(void) */ void fpsimd_save_and_flush_cpu_state(void) { + unsigned long flags; + if (!system_supports_fpsimd()) return; WARN_ON(preemptible()); - get_cpu_fpsimd_context(); + local_irq_save(flags); + __get_cpu_fpsimd_context(); fpsimd_save(); fpsimd_flush_cpu_state(); - put_cpu_fpsimd_context(); + __put_cpu_fpsimd_context(); + local_irq_restore(flags); } #ifdef CONFIG_KERNEL_MODE_NEON -- 2.34.1

2 1

[PATCH OLK-6.6] scsi: qla2xxx: Free sp in error path to fix system crash
by Zheng Qixing 02 Mar '26

02 Mar '26

From: Anil Gurumurthy <agurumurthy(a)marvell.com> stable inclusion from stable-v6.6.125 commit aed16d37696f494288a291b4b477484ed0be774b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13785 CVE: CVE-2025-71232 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ commit 7adbd2b7809066c75f0433e5e2a8e114b429f30f upstream. System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] <TASK> [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] </TASK> [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] <TASK> [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash. Fixes: f352eeb75419 ("scsi: qla2xxx: Add ability to use GPNFT/GNNFT for RSCN handling") Cc: stable(a)vger.kernel.org Signed-off-by: Anil Gurumurthy <agurumurthy(a)marvell.com> Signed-off-by: Nilesh Javali <njavali(a)marvell.com> Reviewed-by: Himanshu Madhani <hmadhani2024(a)gmail.com> Link: https://patch.msgid.link/20251210101604.431868-9-njavali@marvell.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/scsi/qla2xxx/qla_gs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c index c09229b7c516..821e22731fed 100644 --- a/drivers/scsi/qla2xxx/qla_gs.c +++ b/drivers/scsi/qla2xxx/qla_gs.c @@ -3625,8 +3625,8 @@ int qla_fab_async_scan(scsi_qla_host_t *vha, srb_t *sp) if (vha->scan.scan_flags & SF_SCANNING) { spin_unlock_irqrestore(&vha->work_lock, flags); ql_dbg(ql_dbg_disc + ql_dbg_verbose, vha, 0x2012, - "%s: scan active\n", __func__); - return rval; + "%s: scan active for sp:%p\n", __func__, sp); + goto done_free_sp; } vha->scan.scan_flags |= SF_SCANNING; if (!sp) -- 2.39.2

2 1

[PATCH OLK-6.6] scsi: qla2xxx: Delay module unload while fabric scan in progress
by Zheng Qixing 02 Mar '26

02 Mar '26

From: Anil Gurumurthy <agurumurthy(a)marvell.com> stable inclusion from stable-v6.6.125 commit 528b2f1027edfb52af0171f0f4b227fb356dde05 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13782 CVE: CVE-2025-71235 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ commit 8890bf450e0b6b283f48ac619fca5ac2f14ddd62 upstream. System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] <IRQ> [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/all/202512090414.07Waorz0-lkp@intel.com/ Fixes: 783e0dc4f66a ("qla2xxx: Check for device state before unloading the driver.") Cc: stable(a)vger.kernel.org Signed-off-by: Anil Gurumurthy <agurumurthy(a)marvell.com> Signed-off-by: Nilesh Javali <njavali(a)marvell.com> Reviewed-by: Himanshu Madhani <hmadhani2024(a)gmail.com> Link: https://patch.msgid.link/20251210101604.431868-8-njavali@marvell.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/scsi/qla2xxx/qla_os.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c index 7fa7a658ba19..609acc97e887 100644 --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -1194,7 +1194,8 @@ qla2x00_wait_for_hba_ready(scsi_qla_host_t *vha) while ((qla2x00_reset_active(vha) || ha->dpc_active || ha->flags.mbox_busy) || test_bit(FX00_RESET_RECOVERY, &vha->dpc_flags) || - test_bit(FX00_TARGET_SCAN, &vha->dpc_flags)) { + test_bit(FX00_TARGET_SCAN, &vha->dpc_flags) || + (vha->scan.scan_flags & SF_SCANNING)) { if (test_bit(UNLOADING, &base_vha->dpc_flags)) break; msleep(1000); -- 2.39.2

2 1