- Kernel - mailweb.openeuler.org

[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

[PATCH OLK-6.6] erofs: avoid infinite loops due to corrupted subpage compact indexes
by Zizhi Wo 22 Dec '25

22 Dec '25

From: Gao Xiang <hsiangkao(a)linux.alibaba.com> stable inclusion from stable-v6.17.6 commit 8675447a8794983f2b7e694b378112772c17635e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11522 CVE: CVE-2025-68251 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e13d315ae077bb7c3c6027cc292401bc0f4ec683 ] Robert reported an infinite loop observed by two crafted images. The root cause is that `clusterofs` can be larger than `lclustersize` for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515 Move the corresponding check for full compress indexes to `z_erofs_load_lcluster_from_disk()` to also cover subpage compact compress indexes. It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX` check, since it should be placed right after `z_erofs_load_{compact,full}_lcluster()`. Fixes: 8d2517aaeea3 ("erofs: fix up compacted indexes for block size < 4096") Fixes: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()") Reported-by: Robert Morris <rtm(a)csail.mit.edu> Closes: https://lore.kernel.org/r/35167.1760645886@localhost Reviewed-by: Hongbo Li <lihongbo22(a)huawei.com> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/erofs/zmap.c [1. z_erofs_load_full_lcluster() function conflicts due to commit: d69189428d50 ("erofs: clean up z_erofs_load_full_lcluster()"); 2. z_erofs_load_lcluster_from_disk() function conflicts due to commit: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()"); 3. "z_lclusterbits" -> "z_logical_clusterbits" due to commit: efb2aef569b3 ("erofs: add encoded extent on-disk definition"); Both are not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/erofs/zmap.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c index 76566c2cbf63..0603ccd00b3c 100644 --- a/fs/erofs/zmap.c +++ b/fs/erofs/zmap.c @@ -67,10 +67,6 @@ static int z_erofs_load_full_lcluster(struct z_erofs_maprecorder *m, if (advise & Z_EROFS_LI_PARTIAL_REF) m->partialref = true; m->clusterofs = le16_to_cpu(di->di_clusterofs); - if (m->clusterofs >= 1 << vi->z_logical_clusterbits) { - DBG_BUGON(1); - return -EFSCORRUPTED; - } m->pblk = le32_to_cpu(di->di_u.blkaddr); break; default: @@ -276,14 +272,25 @@ static int z_erofs_load_compact_lcluster(struct z_erofs_maprecorder *m, static int z_erofs_load_lcluster_from_disk(struct z_erofs_maprecorder *m, unsigned int lcn, bool lookahead) { - switch (EROFS_I(m->inode)->datalayout) { - case EROFS_INODE_COMPRESSED_FULL: - return z_erofs_load_full_lcluster(m, lcn); - case EROFS_INODE_COMPRESSED_COMPACT: - return z_erofs_load_compact_lcluster(m, lcn, lookahead); - default: - return -EINVAL; + struct erofs_inode *vi = EROFS_I(m->inode); + int err; + + if (vi->datalayout == EROFS_INODE_COMPRESSED_COMPACT) { + err = z_erofs_load_compact_lcluster(m, lcn, lookahead); + } else { + DBG_BUGON(vi->datalayout != EROFS_INODE_COMPRESSED_FULL); + err = z_erofs_load_full_lcluster(m, lcn); } + if (err) + return err; + + if (m->type != Z_EROFS_LCLUSTER_TYPE_NONHEAD && + m->clusterofs >= (1 << vi->z_logical_clusterbits)) { + DBG_BUGON(1); + return -EFSCORRUPTED; + } + + return 0; } static int z_erofs_extent_lookback(struct z_erofs_maprecorder *m, -- 2.39.2

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://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 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] erofs: avoid infinite loops due to corrupted subpage compact indexes
by Zizhi Wo 22 Dec '25

22 Dec '25

From: Gao Xiang <hsiangkao(a)linux.alibaba.com> stable inclusion from stable-v6.17.6 commit 8675447a8794983f2b7e694b378112772c17635e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDF3Q CVE: CVE-2025-68251 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e13d315ae077bb7c3c6027cc292401bc0f4ec683 ] Robert reported an infinite loop observed by two crafted images. The root cause is that `clusterofs` can be larger than `lclustersize` for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515 Move the corresponding check for full compress indexes to `z_erofs_load_lcluster_from_disk()` to also cover subpage compact compress indexes. It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX` check, since it should be placed right after `z_erofs_load_{compact,full}_lcluster()`. Fixes: 8d2517aaeea3 ("erofs: fix up compacted indexes for block size < 4096") Fixes: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()") Reported-by: Robert Morris <rtm(a)csail.mit.edu> Closes: https://lore.kernel.org/r/35167.1760645886@localhost Reviewed-by: Hongbo Li <lihongbo22(a)huawei.com> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/erofs/zmap.c [1. z_erofs_load_full_lcluster() function conflicts due to commit: d69189428d50 ("erofs: clean up z_erofs_load_full_lcluster()"); 2. z_erofs_load_lcluster_from_disk() function conflicts due to commit: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()"); 3. "z_lclusterbits" -> "z_logical_clusterbits" due to commit: efb2aef569b3 ("erofs: add encoded extent on-disk definition"); Both are not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/erofs/zmap.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c index 76566c2cbf63..0603ccd00b3c 100644 --- a/fs/erofs/zmap.c +++ b/fs/erofs/zmap.c @@ -67,10 +67,6 @@ static int z_erofs_load_full_lcluster(struct z_erofs_maprecorder *m, if (advise & Z_EROFS_LI_PARTIAL_REF) m->partialref = true; m->clusterofs = le16_to_cpu(di->di_clusterofs); - if (m->clusterofs >= 1 << vi->z_logical_clusterbits) { - DBG_BUGON(1); - return -EFSCORRUPTED; - } m->pblk = le32_to_cpu(di->di_u.blkaddr); break; default: @@ -276,14 +272,25 @@ static int z_erofs_load_compact_lcluster(struct z_erofs_maprecorder *m, static int z_erofs_load_lcluster_from_disk(struct z_erofs_maprecorder *m, unsigned int lcn, bool lookahead) { - switch (EROFS_I(m->inode)->datalayout) { - case EROFS_INODE_COMPRESSED_FULL: - return z_erofs_load_full_lcluster(m, lcn); - case EROFS_INODE_COMPRESSED_COMPACT: - return z_erofs_load_compact_lcluster(m, lcn, lookahead); - default: - return -EINVAL; + struct erofs_inode *vi = EROFS_I(m->inode); + int err; + + if (vi->datalayout == EROFS_INODE_COMPRESSED_COMPACT) { + err = z_erofs_load_compact_lcluster(m, lcn, lookahead); + } else { + DBG_BUGON(vi->datalayout != EROFS_INODE_COMPRESSED_FULL); + err = z_erofs_load_full_lcluster(m, lcn); } + if (err) + return err; + + if (m->type != Z_EROFS_LCLUSTER_TYPE_NONHEAD && + m->clusterofs >= (1 << vi->z_logical_clusterbits)) { + DBG_BUGON(1); + return -EFSCORRUPTED; + } + + return 0; } static int z_erofs_extent_lookback(struct z_erofs_maprecorder *m, -- 2.39.2

2 1

[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: https://gitee.com/src-openeuler/kernel/issues/IDDEWE 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

[openeuler:OLK-5.10 3420/3420] drivers/cpufreq/intel_pstate.c:1473:6: sparse: sparse: symbol 'notify_hwp_interrupt' was not declared. Should it be static?
by kernel test robot 22 Dec '25

22 Dec '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: e217d5958ee378eb304fb0b4eb6fcb551e555842 [3420/3420] cpufreq: intel_pstate: Process HWP Guaranteed change notification config: x86_64-randconfig-123-20251218 (https://download.01.org/0day-ci/archive/20251222/202512220826.pYRgbdJv-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220826.pYRgbdJv-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/202512220826.pYRgbdJv-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/cpufreq/intel_pstate.c:1473:6: sparse: sparse: symbol 'notify_hwp_interrupt' was not declared. Should it be static? vim +/notify_hwp_interrupt +1473 drivers/cpufreq/intel_pstate.c 1472 > 1473 void notify_hwp_interrupt(void) 1474 { 1475 unsigned int this_cpu = smp_processor_id(); 1476 struct cpudata *cpudata; 1477 unsigned long flags; 1478 u64 value; 1479 1480 if (!READ_ONCE(hwp_active) || !boot_cpu_has(X86_FEATURE_HWP_NOTIFY)) 1481 return; 1482 1483 rdmsrl_safe(MSR_HWP_STATUS, &value); 1484 if (!(value & 0x01)) 1485 return; 1486 1487 spin_lock_irqsave(&hwp_notify_lock, flags); 1488 1489 if (!cpumask_test_cpu(this_cpu, &hwp_intr_enable_mask)) 1490 goto ack_intr; 1491 1492 /* 1493 * Currently we never free all_cpu_data. And we can't reach here 1494 * without this allocated. But for safety for future changes, added 1495 * check. 1496 */ 1497 if (unlikely(!READ_ONCE(all_cpu_data))) 1498 goto ack_intr; 1499 1500 /* 1501 * The free is done during cleanup, when cpufreq registry is failed. 1502 * We wouldn't be here if it fails on init or switch status. But for 1503 * future changes, added check. 1504 */ 1505 cpudata = READ_ONCE(all_cpu_data[this_cpu]); 1506 if (unlikely(!cpudata)) 1507 goto ack_intr; 1508 1509 schedule_delayed_work(&cpudata->hwp_notify_work, msecs_to_jiffies(10)); 1510 1511 spin_unlock_irqrestore(&hwp_notify_lock, flags); 1512 1513 return; 1514 1515 ack_intr: 1516 wrmsrl_safe(MSR_HWP_STATUS, 0); 1517 spin_unlock_irqrestore(&hwp_notify_lock, flags); 1518 } 1519 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 3415/3415] arch/arm64/kernel/fpsimd.c:158:12: warning: 'get_sve_default_vl' defined but not used
by kernel test robot 22 Dec '25

22 Dec '25

Hi Mark, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: bf04fdf1fcc0040e6c81b413cdae84c0eb9212b9 [3415/3415] arm64/sve: Track vector lengths for tasks in an array config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251222/202512220837.hZSDu6Y4-lkp@…) compiler: aarch64-linux-gcc (GCC) 15.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220837.hZSDu6Y4-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/202512220837.hZSDu6Y4-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/kernel/fpsimd.c:158:12: warning: 'get_sve_default_vl' defined but not used [-Wunused-function] 158 | static int get_sve_default_vl(void) | ^~~~~~~~~~~~~~~~~~ vim +/get_sve_default_vl +158 arch/arm64/kernel/fpsimd.c 1e570f512cbdc5 Dave Martin 2020-06-10 157 1e570f512cbdc5 Dave Martin 2020-06-10 @158 static int get_sve_default_vl(void) 1e570f512cbdc5 Dave Martin 2020-06-10 159 { 68da302c8ae303 Mark Brown 2023-11-28 160 return get_default_vl(ARM64_VEC_SVE); 1e570f512cbdc5 Dave Martin 2020-06-10 161 } 79ab047c75d6a9 Dave Martin 2017-10-31 162 :::::: The code at line 158 was first introduced by commit :::::: 1e570f512cbdc5e9e401ba640d9827985c1bea1e arm64/sve: Eliminate data races on sve_default_vl :::::: TO: Dave Martin <Dave.Martin(a)arm.com> :::::: CC: Will Deacon <will(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 3415/3415] arch/arm64/mm/init.c:730:6: warning: no previous prototype for 'ascend_enable_all_features'
by kernel test robot 22 Dec '25

22 Dec '25

Hi Wang, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: 66ae8ddda388386daea0623a65ea2ac85c24ca00 [3415/3415] ascend/arm64: Add ascend_enable_all kernel parameter config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251222/202512220606.726hmC01-lkp@…) compiler: aarch64-linux-gcc (GCC) 15.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220606.726hmC01-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/202512220606.726hmC01-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/mm/init.c:730:6: warning: no previous prototype for 'ascend_enable_all_features' [-Wmissing-prototypes] 730 | void ascend_enable_all_features(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ vim +/ascend_enable_all_features +730 arch/arm64/mm/init.c 729 > 730 void ascend_enable_all_features(void) 731 { 732 if (IS_ENABLED(CONFIG_ASCEND_DVPP_MMAP)) 733 enable_mmap_dvpp = 1; 734 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0