- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/2] Fix CVE-2025-39810
by Zhao Yipeng 22 Dec '25

22 Dec '25

Patch #1 is the prerequisite patch, and Patch #2 fixes CVE-2025-39810. Michael Chan (1): [Backport] bnxt_en: Fix possible crash after creating sw mqprio TCs Sreekanth Reddy (1): [Backport] bnxt_en: Fix memory corruption when FW resources change during ifdown drivers/net/ethernet/broadcom/bnxt/bnxt.c | 34 ++++++++++++++----- drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 + drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 2 +- .../net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 +-- drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 2 +- 5 files changed, 30 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10] hisi: l3t: enable l3t with specific cpuid
by Wupeng Ma 22 Dec '25

22 Dec '25

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8282 -------------------------------- L3t is only work with specific cpus, now add checker during init to make sure this is enabled with specific cpus. Fixes: c40d971092ff ("hisi: l3t: Add L3 cache driver for hisi") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- arch/arm64/include/asm/cputype.h | 2 ++ drivers/soc/hisilicon/l3t.c | 8 ++++++++ 2 files changed, 10 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index b3b1977e9980..ca90d0e13ad6 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -113,6 +113,7 @@ #define HISI_CPU_PART_TSV110 0xD01 #define HISI_CPU_PART_TSV200 0xD02 #define HISI_CPU_PART_LINXICORE9100 0xD02 +#define HISI_CPU_PART_HIP10 0xD03 #define PHYTIUM_CPU_PART_1500A 0X660 #define PHYTIUM_CPU_PART_2000AHK 0X661 @@ -165,6 +166,7 @@ #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX) #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110) #define MIDR_HISI_TSV200 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV200) +#define MIDR_HISI_HIP10 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP10) #define MIDR_HISI_LINXICORE9100 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_LINXICORE9100) #define MIDR_FT_1500A MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_1500A) #define MIDR_FT_2000AHK MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000AHK) diff --git a/drivers/soc/hisilicon/l3t.c b/drivers/soc/hisilicon/l3t.c index 35106e091098..69e65d659a35 100644 --- a/drivers/soc/hisilicon/l3t.c +++ b/drivers/soc/hisilicon/l3t.c @@ -264,6 +264,14 @@ static struct platform_driver hisi_l3t_driver = { static int __init hisi_l3t_init(void) { + static const struct midr_range l3t_support_list[] = { + MIDR_ALL_VERSIONS(MIDR_HISI_TSV200), + MIDR_ALL_VERSIONS(MIDR_HISI_HIP10), + {} + }; + if (!is_midr_in_range_list(read_cpuid_id(), l3t_support_list)) + return -ENODEV; + mutex_init(&l3t_mutex); xa_init(&l3t_mapping); -- 2.43.0

2 1

[PATCH OLK-6.6] timers: Fix NULL function pointer race in timer_shutdown_sync()
by Jinjie Ruan 22 Dec '25

22 Dec '25

From: Yipeng Zou <zouyipeng(a)huawei.com> stable inclusion from stable-v6.6.118 commit 6665fbd7730b26d770c232b20d1b907e6a67a914 category: bugfix bugzilla: https://gitcode.com/src-openeuler/kernel/issues/11566 CVE: CVE-2025-68214 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream. There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 63a8ce7177dd..4a2aeaa85af3 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1413,10 +1413,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags); -- 2.34.1

2 1

[PATCH OLK-5.10] hisi: l3t: enable l3t with specific cpuid
by Wupeng Ma 22 Dec '25

22 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/8282 -------------------------------- L3t is only work with specific cpus, now add checker during init to make sure this is enabled with specific cpus. Fixes: c40d971092ff ("hisi: l3t: Add L3 cache driver for hisi") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- arch/arm64/include/asm/cputype.h | 2 ++ drivers/soc/hisilicon/l3t.c | 8 ++++++++ 2 files changed, 10 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index b3b1977e9980..ca90d0e13ad6 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -113,6 +113,7 @@ #define HISI_CPU_PART_TSV110 0xD01 #define HISI_CPU_PART_TSV200 0xD02 #define HISI_CPU_PART_LINXICORE9100 0xD02 +#define HISI_CPU_PART_HIP10 0xD03 #define PHYTIUM_CPU_PART_1500A 0X660 #define PHYTIUM_CPU_PART_2000AHK 0X661 @@ -165,6 +166,7 @@ #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX) #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110) #define MIDR_HISI_TSV200 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV200) +#define MIDR_HISI_HIP10 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP10) #define MIDR_HISI_LINXICORE9100 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_LINXICORE9100) #define MIDR_FT_1500A MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_1500A) #define MIDR_FT_2000AHK MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000AHK) diff --git a/drivers/soc/hisilicon/l3t.c b/drivers/soc/hisilicon/l3t.c index 35106e091098..69e65d659a35 100644 --- a/drivers/soc/hisilicon/l3t.c +++ b/drivers/soc/hisilicon/l3t.c @@ -264,6 +264,14 @@ static struct platform_driver hisi_l3t_driver = { static int __init hisi_l3t_init(void) { + static const struct midr_range l3t_support_list[] = { + MIDR_ALL_VERSIONS(MIDR_HISI_TSV200), + MIDR_ALL_VERSIONS(MIDR_HISI_HIP10), + {} + }; + if (!is_midr_in_range_list(read_cpuid_id(), l3t_support_list)) + return -ENODEV; + mutex_init(&l3t_mutex); xa_init(&l3t_mapping); -- 2.43.0

2 1

[PATCH OLK-6.6] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitcode.com/src-openeuler/kernel/issues/11604 CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 9a31f3db713c..1f0871be9d53 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -865,6 +865,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[PATCH OLK-5.10] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitcode.com/src-openeuler/kernel/issues/11604 CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index e0aa2dfb89d1..1885c45fa6eb 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -809,6 +809,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[PATCH OLK-6.6] timers: Fix NULL function pointer race in timer_shutdown_sync()
by Jinjie Ruan 22 Dec '25

22 Dec '25

From: Yipeng Zou <zouyipeng(a)huawei.com> stable inclusion from stable-v6.6.118 commit 6665fbd7730b26d770c232b20d1b907e6a67a914 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11566 CVE: CVE-2025-68214 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream. There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 63a8ce7177dd..4a2aeaa85af3 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1413,10 +1413,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags); -- 2.34.1

2 1

[PATCH OLK-6.6] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWO CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 9a31f3db713c..1f0871be9d53 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -865,6 +865,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[openeuler:OLK-5.10 3415/3415] drivers/irqchip/irq-gic-v3-its.c:504:6: warning: no previous prototype for 'build_devid_pools'
by kernel test robot 22 Dec '25

22 Dec '25

Hi Jia, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: af552f9d957def499065ed6e194bcd5f0c75dbc5 [3415/3415] irqchip/gic-v3-its: Move build_devid_pools from its to acpi iort init config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251222/202512220941.znSG62CM-lkp@…) compiler: aarch64-linux-gcc (GCC) 15.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220941.znSG62CM-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512220941.znSG62CM-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/irqchip/irq-gic-v3-its.c:504:6: warning: no previous prototype for 'build_devid_pools' [-Wmissing-prototypes] 504 | void build_devid_pools(void) | ^~~~~~~~~~~~~~~~~ vim +/build_devid_pools +504 drivers/irqchip/irq-gic-v3-its.c 500 501 /* 502 * Currently we only build *one* devid pool. 503 */ > 504 void build_devid_pools(void) 505 { 506 struct its_node *its; 507 508 its = list_first_entry(&its_nodes, struct its_node, entry); 509 if (readl_relaxed(its->base + GITS_IIDR) != 0x00051736) 510 return; 511 512 if (!probe_devid_pool_one()) 513 rsv_devid_pool_cap = true; 514 515 if (rsv_devid_pool_cap) 516 pr_info("ITS: reserved device id pools enabled\n"); 517 } 518 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] ftrace: Fix softlockup in ftrace_module_enable
by Tengda Wu 22 Dec '25

22 Dec '25

From: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> stable inclusion from stable-v6.6.119 commit e81e6d6d99b16dae11adbeda5c996317942a940c category: bugfix bugzilla: http://gitcode.com/src-openeuler/kernel/issues/11609 CVE: CVE-2025-68173 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 15785a729a0c..398992597685 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6873,6 +6873,8 @@ void ftrace_module_enable(struct module *mod) if (!within_module(rec->ip, mod)) break; + cond_resched(); + /* Weak functions should still be ignored */ if (!test_for_valid_rec(rec)) { /* Clear all other flags. Should not be enabled anyway */ -- 2.34.1

2 1