April 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/1] Fix kmemleak false positive
by Lin Yujun 02 Apr '25

02 Apr '25

Waiman Long (1): efi/arm64: Fix kmemleak false positive in arm64_efi_rt_init() arch/arm64/kernel/efi.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10] powerpc: Fix save r13 on kprobe/ftrace entry
by Chen Zhongjin 02 Apr '25

02 Apr '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBY4FQ -------------------------------- In kprobe and ftrace entry, r13 will be saved to stack and restored after handler. There is a period between entry and handler where the task can be scheduled, then the r13 for one cpu will be restored to another cpu, and cause the paca_ptrs wrong. Fix this by stop saving and restoring r13 in kprobe/ftrace entry. Fixes: 51c9c0843993 ("powerpc/kprobes: Implement Optprobes") Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- arch/powerpc/kernel/optprobes_head.S | 10 ++++++---- arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 10 ++++++---- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/optprobes_head.S b/arch/powerpc/kernel/optprobes_head.S index ff8ba4d3824d..9d803cc2392f 100644 --- a/arch/powerpc/kernel/optprobes_head.S +++ b/arch/powerpc/kernel/optprobes_head.S @@ -36,8 +36,9 @@ optprobe_template_entry: addi r0,r1,INT_FRAME_SIZE std r0,GPR1(r1) SAVE_10GPRS(2,r1) - SAVE_10GPRS(12,r1) - SAVE_10GPRS(22,r1) + SAVE_GPR(12,r1) + SAVE_10GPRS(14,r1) + SAVE_8GPRS(24,r1) /* Save SPRS */ mfmsr r5 std r5,_MSR(r1) @@ -119,8 +120,9 @@ optprobe_template_call_emulate: mtcr r5 REST_GPR(0,r1) REST_10GPRS(2,r1) - REST_10GPRS(12,r1) - REST_10GPRS(22,r1) + REST_GPR(12,r1) + REST_10GPRS(14,r1) + REST_8GPRS(24,r1) /* Restore the previous SP */ addi r1,r1,INT_FRAME_SIZE diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S index 0bc39ff53233..32e354d9ee9b 100644 --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S @@ -51,8 +51,9 @@ _GLOBAL(ftrace_regs_caller) cmpdi r3, 0 beq ftrace_no_trace - SAVE_10GPRS(12, r1) - SAVE_10GPRS(22, r1) + SAVE_GPR(12,r1) + SAVE_10GPRS(14,r1) + SAVE_8GPRS(24,r1) /* Save previous stack pointer (r1) */ addi r8, r1, SWITCH_FRAME_SIZE+STACK_FRAME_MIN_SIZE @@ -115,8 +116,9 @@ ftrace_regs_call: /* Restore gprs */ REST_GPR(0,r1) REST_10GPRS(2,r1) - REST_10GPRS(12,r1) - REST_10GPRS(22,r1) + REST_GPR(12,r1) + REST_10GPRS(14,r1) + REST_8GPRS(24,r1) /* Restore possibly modified LR */ ld r0, _LINK(r1) -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 1537/1537] kernel/seccomp.o: warning: objtool: do_seccomp()+0xa8a: unreachable instruction
by kernel test robot 02 Apr '25

02 Apr '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 7951fd324625a8af5097e1476cdc8c33c6009b48 commit: e5d58f5ee731b2ff4e5c801cb875c804c63593e4 [1537/1537] seccomp: Invalidate seccomp mode to catch death failures config: x86_64-buildonly-randconfig-004-20250331 (https://download.01.org/0day-ci/archive/20250402/202504021615.GKzmsAcB-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250402/202504021615.GKzmsAcB-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/202504021615.GKzmsAcB-lkp@intel.com/ All warnings (new ones prefixed by >>): kernel/seccomp.c:190: warning: Function parameter or member 'ret' not described in 'ACTION_ONLY' kernel/seccomp.c:190: warning: Excess function parameter 'sd' description in 'ACTION_ONLY' kernel/seccomp.c:190: warning: Excess function parameter 'match' description in 'ACTION_ONLY' kernel/seccomp.c:320: warning: Function parameter or member 'flags' not described in 'seccomp_sync_threads' >> kernel/seccomp.o: warning: objtool: do_seccomp()+0xa8a: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment
by Chen Zhongjin 02 Apr '25

02 Apr '25

From: Jann Horn <jannh(a)google.com> mainline inclusion from mainline-v6.15-rc1 commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBYAPJ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header. This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places. Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines. Fix it by moving the "stack = " assignment back where it belongs. Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@g… Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- arch/x86/kernel/dumpstack.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index f18ca44c904b..52dc5839d1e8 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -195,6 +195,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, printk("%sCall Trace:\n", log_lvl); unwind_start(&state, task, regs, stack); + stack = stack ?: get_stack_pointer(task, regs); regs = unwind_get_entry_regs(&state, &partial); /* @@ -213,9 +214,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, * - hardirq stack * - entry stack */ - for (stack = stack ?: get_stack_pointer(task, regs); - stack; - stack = stack_info.next_sp) { + for (; stack; stack = stack_info.next_sp) { const char *stack_name; stack = PTR_ALIGN(stack, sizeof(long)); -- 2.25.1

2 1

[PATCH v3 OLK-6.6 0/6] Support the FEAT_HDBSS introduced in Armv9.5
by Zhenyu Ye 02 Apr '25

02 Apr '25

From: eillon <yezhenyu2(a)huawei.com> hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IB103D CVE: NA ---------------------------------------------------------------------- This series of patches add support to the Hardware Dirty state tracking Structure(HDBSS) feature, which is introduced by the ARM architecture in the DDI0601(ID121123) version. The HDBSS feature is an extension to the architecture that enhances tracking translation table descriptors' dirty state, identified as FEAT_HDBSS. The goal of this feature is to reduce the cost of surveying for dirtied granules, with minimal effect on recording when a granule has been dirtied. The purpose of this feature is to make the execution overhead of live migration lower to both the guest and the host, compared to existing approaches (write-protect or search stage 2 tables). After these patches, users(such as qemu) can use the KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl to enable or disable the HDBSS feature before and after the live migration. Changes in v3: - fix kabi broken Changes in v2: - adapt the commit format See patches for details, Thanks. eillon (5): arm64/sysreg: add HDBSS related register information arm64/kvm: support set the DBM attr during memory abort arm64/kvm: using ioctl to enable/disable the HDBSS feature arm64/kvm: support to handle the HDBSSF event arm64/config: add config to control whether enable HDBSS feature arch/arm64/Kconfig | 12 ++++ arch/arm64/configs/openeuler_defconfig | 6 ++ arch/arm64/include/asm/cpufeature.h | 14 ++++ arch/arm64/include/asm/esr.h | 2 + arch/arm64/include/asm/kvm_arm.h | 1 + arch/arm64/include/asm/kvm_host.h | 8 +++ arch/arm64/include/asm/kvm_mmu.h | 14 ++++ arch/arm64/include/asm/kvm_pgtable.h | 1 + arch/arm64/include/asm/sysreg.h | 14 ++++ arch/arm64/kvm/arm.c | 88 ++++++++++++++++++++++++++ arch/arm64/kvm/handle_exit.c | 50 +++++++++++++++ arch/arm64/kvm/hyp/pgtable.c | 12 ++++ arch/arm64/kvm/hyp/vhe/switch.c | 3 + arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 4 ++ arch/arm64/kvm/mmu.c | 17 ++++- arch/arm64/kvm/reset.c | 9 +++ arch/arm64/tools/sysreg | 28 ++++++++ include/linux/kvm_host.h | 3 + include/uapi/linux/kvm.h | 2 + tools/include/uapi/linux/kvm.h | 2 + 20 files changed, 289 insertions(+), 1 deletion(-) -- 2.39.3

2 7

[PATCH OLK-5.10] x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment
by Chen Zhongjin 02 Apr '25

02 Apr '25

From: Jann Horn <jannh(a)google.com> mainline inclusion from mainline-v6.15-rc1 commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBYAPJ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header. This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places. Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines. Fix it by moving the "stack = " assignment back where it belongs. Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@g… Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- arch/x86/kernel/dumpstack.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index b726174024da..d9cbcdbdf1e0 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -195,6 +195,7 @@ void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, printk("%sCall Trace:\n", log_lvl); unwind_start(&state, task, regs, stack); + stack = stack ?: get_stack_pointer(task, regs); regs = unwind_get_entry_regs(&state, &partial); /* @@ -213,9 +214,7 @@ void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, * - hardirq stack * - entry stack */ - for (stack = stack ?: get_stack_pointer(task, regs); - stack; - stack = stack_info.next_sp) { + for (; stack; stack = stack_info.next_sp) { const char *stack_name; stack = PTR_ALIGN(stack, sizeof(long)); -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] Sync two patches to olk
by Chen Zhongjin 02 Apr '25

02 Apr '25

See: https://gitee.com/openeuler/kernel/issues/IBY4FJ https://gitee.com/openeuler/kernel/issues/IBY4FQ Chen Zhongjin (2): kprobes: Fix deadlock when unwinding kretprobe_trampoline powerpc: Fix save r13 on kprobe/ftrace entry arch/powerpc/kernel/optprobes_head.S | 10 ++++++---- arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 10 ++++++---- kernel/kprobes.c | 9 +++++++-- 3 files changed, 19 insertions(+), 10 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS V1 0/2] fix-CVE-2022-49538
by Cheng Yu 02 Apr '25

02 Apr '25

fix-CVE-2022-49538 Amadeusz Sławiński (1): ALSA: jack: Access input_dev under mutex Takashi Iwai (1): ALSA: jack: Fix mutex call in snd_jack_report() include/sound/jack.h | 1 + sound/core/jack.c | 39 +++++++++++++++++++++++++++++---------- 2 files changed, 30 insertions(+), 10 deletions(-) -- 2.25.1

2 3

[openeuler:OLK-5.10 2830/2830] fs/ext4/file.o: warning: objtool: ext4_file_write_iter()+0x893: unreachable instruction
by kernel test robot 02 Apr '25

02 Apr '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1a6f72935307d39713f310345f6049fcc3058091 commit: 52c6fec939dd6f0de6d534d8b08ac06be8cfe5c4 [2830/2830] ext4: properly sync file size update after O_SYNC direct IO config: x86_64-buildonly-randconfig-004-20250331 (https://download.01.org/0day-ci/archive/20250402/202504021552.RjBa0DvI-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250402/202504021552.RjBa0DvI-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/202504021552.RjBa0DvI-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/ext4/file.o: warning: objtool: ext4_file_write_iter()+0x893: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] perf/core: Fix pmus_lock vs. pmus_srcu ordering
by Luo Gengkun 02 Apr '25

02 Apr '25

From: Peter Zijlstra <peterz(a)infradead.org> stable inclusion from stable-v6.6.83 commit 7c823e4c30d6fdc16089e13924260086eaea76be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBXQNU Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2565e42539b120b81a68a58da961ce5d1e34eac8 ] Commit a63fbed776c7 ("perf/tracing/cpuhotplug: Fix locking order") placed pmus_lock inside pmus_srcu, this makes perf_pmu_unregister() trip lockdep. Move the locking about such that only pmu_idr and pmus (list) are modified while holding pmus_lock. This avoids doing synchronize_srcu() while holding pmus_lock and all is well again. Fixes: a63fbed776c7 ("perf/tracing/cpuhotplug: Fix locking order") Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20241104135517.679556858@infradead.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 0b9e703641d1..9b5d35c4a3ec 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -11670,6 +11670,8 @@ void perf_pmu_unregister(struct pmu *pmu) { mutex_lock(&pmus_lock); list_del_rcu(&pmu->entry); + idr_remove(&pmu_idr, pmu->type); + mutex_unlock(&pmus_lock); /* * We dereference the pmu list under both SRCU and regular RCU, so @@ -11679,7 +11681,6 @@ void perf_pmu_unregister(struct pmu *pmu) synchronize_rcu(); free_percpu(pmu->pmu_disable_count); - idr_remove(&pmu_idr, pmu->type); if (pmu_bus_running && pmu->dev && pmu->dev != PMU_NULL_DEV) { if (pmu->nr_addr_filters) device_remove_file(pmu->dev, &dev_attr_nr_addr_filters); @@ -11687,7 +11688,6 @@ void perf_pmu_unregister(struct pmu *pmu) put_device(pmu->dev); } free_pmu_context(pmu); - mutex_unlock(&pmus_lock); } EXPORT_SYMBOL_GPL(perf_pmu_unregister); -- 2.34.1

2 1