July 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 v7 0/3] arm64: Add hardware xcall framework support
by Jinjie Ruan 29 Jul '25

29 Jul '25

Add hardware xcall framework support. Changes in v7: - Add missing lock for xinfo syscall table copy. - Check xcall entry under lock for set_hw_xcall_entry(). - Clear ACTLR_ELx_XCALL when xcall_scno_count count to zero to reduce overhead. Changes in v6: - Use system_uses_xcall_xint() instead of static key for hardware xcall. - xcall_scno_enabled -> xcall_scno_count for each task_struct. - Use xcall_scno_enabled instead of static_branch_unlikely() for performance-insensitive code. - Some cleanup. Changes in v5: - Not adjust the software xcall and hardware xcall hwcap detect order. - Not udapte xcall 1.0 enrty code. - Some cleanup. Changes in v4: - Merge the percpu and csel patch. - Use static key to improve the software and hardware xcall code. - Some cleanup. - Fix a build problem. Changes in v3: - Optimize the use of hardware xcall and not use them at the same time. - Use syscall table instead of xcall enable bitmap in hardware xcall. - Use percpu syscall table cache to simplfy code. - Use csel to improve the jump instruction. Changes in v2: - Split software xcall and hardware xcall code and use same bitmap to check xcall enable. Jinjie Ruan (3): arm64: Refactor the xcall proc code arm64: Reserve a kabi in task_struct exclusively for xcall arm64: Add hardware xcall framework support arch/arm64/Kconfig.turbo | 1 + arch/arm64/include/asm/cpufeature.h | 2 - arch/arm64/include/asm/exception.h | 5 + arch/arm64/include/asm/mmu_context.h | 7 + arch/arm64/include/asm/xcall.h | 96 +++++++++++++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/asm-offsets.c | 2 +- arch/arm64/kernel/cpufeature.c | 41 +++--- arch/arm64/kernel/entry-common.c | 2 +- arch/arm64/kernel/entry.S | 6 +- arch/arm64/kernel/xcall/Makefile | 2 + arch/arm64/kernel/xcall/entry.S | 195 +++++++++++++++++++++++++++ arch/arm64/kernel/xcall/xcall.c | 77 +++++++++++ fs/proc/Makefile | 1 + fs/proc/base.c | 109 --------------- fs/proc/internal.h | 4 + fs/proc/proc_xcall.c | 178 ++++++++++++++++++++++++ include/linux/sched.h | 2 +- kernel/fork.c | 15 +-- 19 files changed, 605 insertions(+), 141 deletions(-) create mode 100644 arch/arm64/include/asm/xcall.h create mode 100644 arch/arm64/kernel/xcall/Makefile create mode 100644 arch/arm64/kernel/xcall/entry.S create mode 100644 arch/arm64/kernel/xcall/xcall.c create mode 100644 fs/proc/proc_xcall.c -- 2.34.1

2 4

[PATCH OLK-6.6] arm64/nmi: fix using wrong nmi check
by Yang Yingliang 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I90N2C CVE: NA ---------------------------------------------------------------------- If ARM64_HAS_NMI is enabled, it doesn't mean NMI is enabled. When NMI is enabled, ARM64_USES_NMI is set to true, so use it instead. Fixes: 1c203efa0a42 ("arm64/asm: Introduce assembly macros for managing ALLINT") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 38b23786aeb4..d54615963885 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -36,7 +36,7 @@ .macro disable_allint #ifdef CONFIG_ARM64_NMI -alternative_if ARM64_HAS_NMI +alternative_if ARM64_USES_NMI msr_s SYS_ALLINT_SET, xzr alternative_else_nop_endif #endif @@ -44,7 +44,7 @@ alternative_else_nop_endif .macro enable_allint #ifdef CONFIG_ARM64_NMI -alternative_if ARM64_HAS_NMI +alternative_if ARM64_USES_NMI msr_s SYS_ALLINT_CLR, xzr alternative_else_nop_endif #endif -- 2.25.1

2 1

[PATCH OLK-5.10] arm-smmu-v3: adjust ecmdq log level
by Yin Tirui 29 Jul '25

29 Jul '25

From: Tirui Yin <yintirui(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBW5SK -------------------------------- If SMMU is detected to support ECMDQ, a large number of logs will be printed during initialization. Adjust log level of ECMDQ messages from info to debug. Fixes: d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") Signed-off-by: Tirui Yin <yintirui(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 6389a1694188..524b7c2cf413 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -4495,7 +4495,7 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device *smmu, } if (!WARN_ON(q->base_dma & (qsz - 1))) { - dev_info(smmu->dev, "allocated %u entries for %s\n", + dev_dbg(smmu->dev, "allocated %u entries for %s\n", 1 << q->llq.max_n_shift, name); } -- 2.43.0

2 1

[PATCH OLK-6.6] arm-smmu-v3: adjust ecmdq log level
by Yin Tirui 29 Jul '25

29 Jul '25

From: Tirui Yin <yintirui(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBW5SK -------------------------------- If SMMU is detected to support ECMDQ, a large number of logs will be printed during initialization. Adjust log level of ECMDQ messages from info to debug. Fixes: d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") Signed-off-by: Tirui Yin <yintirui(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 6389a1694188..524b7c2cf413 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -4495,7 +4495,7 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device *smmu, } if (!WARN_ON(q->base_dma & (qsz - 1))) { - dev_info(smmu->dev, "allocated %u entries for %s\n", + dev_dbg(smmu->dev, "allocated %u entries for %s\n", 1 << q->llq.max_n_shift, name); } -- 2.43.0

2 1

openEuler Kernel SIG双周例会
by openEuler conference 29 Jul '25

29 Jul '25

您好！ Kernel 邀请您参加 2025-08-01 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，也可填报至会议纪要看板）会议链接：https://meeting.huaweicloud.com:36443/#/j/962225783 会议纪要：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 2025-08-01 14:00, The subject of the conference is openEuler Kernel SIG双周例会 Summary: 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，也可填报至会议纪要看板） You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/962225783 Add topics at https://etherpad.openeuler.org/p/Kernel-meetings More information: https://www.openeuler.org/en/

1 0

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] dm-bufio: fix sched in atomic context
by Li Lingfeng 29 Jul '25

29 Jul '25

From: Sheng Yong <shengyong1(a)xiaomi.com> mainline inclusion from mainline-v6.17-rc1 commit b1bf1a782fdf5c482215c0c661b5da98b8e75773 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPD56 CVE: CVE-2025-38496 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: <TASK> dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 </TASK> That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] Cc: stable(a)vger.kernel.org # v6.4+ Fixes: 450e8dee51aa ("dm bufio: improve concurrent IO performance") Signed-off-by: Wang Shuai <wangshuai12(a)xiaomi.com> Signed-off-by: Sheng Yong <shengyong1(a)xiaomi.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Conflicts: drivers/md/dm-bufio.c [Commit 9769378133bb ("dm-bufio: remove maximum age based eviction") removed the definition of __evict_many().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-bufio.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index 30ddfb21f658..376d2d8278f7 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -2701,7 +2701,11 @@ static unsigned long __evict_many(struct dm_bufio_client *c, __make_buffer_clean(b); __free_buffer_wake(b); - cond_resched(); + if (need_resched()) { + dm_bufio_unlock(c); + cond_resched(); + dm_bufio_lock(c); + } } return count; -- 2.46.1

2 1

[PATCH OLK-6.6] livepatch: fix insn length check
by Pan Taixi 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPCXQ ---------------------------------------- When livepatch checks the instruction length while ftrace is modifying the instruction, livepatch might read incorrect insn length. This tries to fix the issue by holding jump_label_lock() when doing insn check. Fixes: 4fe95df15c61 ("livepatch/core: Avoid conflict with static {call,key}") Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- kernel/livepatch/core.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index bb7ecc516b4a..6c5b3f52967a 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -21,6 +21,7 @@ #include <linux/completion.h> #include <linux/memory.h> #include <linux/rcupdate.h> +#include <linux/jump_label.h> #include <asm/cacheflush.h> #include "core.h" #ifdef CONFIG_LIVEPATCH_FTRACE @@ -1602,18 +1603,11 @@ static int check_address_conflict(struct klp_patch *patch) { struct klp_object *obj; struct klp_func *func; - int ret; + int ret = 0; void *start; void *end; - /* - * Locks seem required as comment of jump_label_text_reserved() said: - * Caller must hold jump_label_mutex. - * But looking into implementation of jump_label_text_reserved() and - * static_call_text_reserved(), call sites of every jump_label or static_call - * are checked, and they won't be changed after corresponding module inserted, - * so no need to take jump_label_lock and static_call_lock here. - */ + jump_label_lock(); klp_for_each_object(patch, obj) { klp_for_each_func(obj, func) { start = func->old_func; @@ -1622,17 +1616,21 @@ static int check_address_conflict(struct klp_patch *patch) if (ret) { pr_err("'%s' has static key in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } ret = static_call_text_reserved(start, end); if (ret) { pr_err("'%s' has static call in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } } } - return 0; +out: + jump_label_unlock(); + return ret; } static int state_show(struct seq_file *m, void *v) -- 2.34.1

2 1

[PATCH OLK-5.10] eventpoll: Fix return fixed cpu bug in set_prefetch_numa_cpu()
by Jinjie Ruan 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/release-management/issues/IC9Q31 -------------------------------- The original intention of set_prefetch_numa_cpu() was to randomly select a CPU from the pfi->related_cpu range based on fd. The function of cpumask_next(int n, const struct cpumask *srcp) is, in the given CPU mask "srcp", find the next CPU number that is set (i.e., set to 1) starting from the specified position n. So cpumask_next() in set_prefetch_numa_cpu() will always return cpumask_first(&related_cpus) if the following conditions are met: fd % cpumask_weight(&related_cpus) < cpumask_first(&related_cpus) But use the calculated offset in cpumask_next() may also not be correct if the "related_cpus" is discontinuous. So count the nth cpu in "related_cpus" to return the prefetch cpu. Fixes: 7e1291339cb5 ("eventpoll: Support xcall async prefetch") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- fs/eventpoll.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index dd11e92994c9..4360444afb83 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -949,6 +949,20 @@ static void prefetch_work_fn(struct work_struct *work) trace_epoll_rc_ready(pfi->file, pfi->len); } +static int get_nth_cpu_in_cpumask(const struct cpumask *mask, int n) +{ + int count = 0; + int cpu; + + for_each_cpu(cpu, mask) { + if (count == n) + return cpu; + count++; + } + + return cpumask_first(mask); +} + static void set_prefetch_numa_cpu(struct prefetch_item *pfi, int fd) { int cur_cpu = smp_processor_id(); @@ -959,11 +973,9 @@ static void set_prefetch_numa_cpu(struct prefetch_item *pfi, int fd) cpumask_and(&pfi->related_cpus, cpu_cpu_mask(cur_cpu), cpu_online_mask); if (cpumask_intersects(&tmp, &pfi->related_cpus)) cpumask_and(&pfi->related_cpus, &pfi->related_cpus, &tmp); - cpu = cpumask_next(fd % cpumask_weight(&pfi->related_cpus), - &pfi->related_cpus); - if (cpu > cpumask_last(&pfi->related_cpus)) - cpu = cpumask_first(&pfi->related_cpus); - pfi->cpu = cpu; + + pfi->cpu = get_nth_cpu_in_cpumask(&pfi->related_cpus, + fd % cpumask_weight(&pfi->related_cpus)); } static struct prefetch_item *alloc_prefetch_item(struct epitem *epi) -- 2.34.1

2 1