- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] bpf: Fix WARN() in get_bpf_raw_tp_regs
by Pu Lehui 16 May '25

16 May '25

From: Tao Chen <chen.dylane(a)linux.dev> maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC8D46 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id… -------------------------------- syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first. Fixes: 9594dc3c7e71 ("bpf: fix nested bpf tracepoints with per-cpu data") Reported-by: syzbot+45b0c89a0fc7ae8dbadc(a)syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Tao Chen <chen.dylane(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20250513042747.757042-1-chen.dylane@linux.dev Closes: https://lore.kernel.org/bpf/8bc2554d-1052-4922-8832-e0078a033e1d@gmail.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 042077a3abfe..423fb97a3f27 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1834,7 +1834,7 @@ static struct pt_regs *get_bpf_raw_tp_regs(void) struct bpf_raw_tp_regs *tp_regs = this_cpu_ptr(&bpf_raw_tp_regs); int nest_level = this_cpu_inc_return(bpf_raw_tp_nest_level); - if (WARN_ON_ONCE(nest_level > ARRAY_SIZE(tp_regs->regs))) { + if (nest_level > ARRAY_SIZE(tp_regs->regs)) { this_cpu_dec(bpf_raw_tp_nest_level); return ERR_PTR(-EBUSY); } -- 2.34.1

2 1

[PATCH OLK-5.10] bpf: Fix WARN() in get_bpf_raw_tp_regs
by Pu Lehui 16 May '25

16 May '25

From: Tao Chen <chen.dylane(a)linux.dev> maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC8D46 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id… -------------------------------- syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first. Fixes: 9594dc3c7e71 ("bpf: fix nested bpf tracepoints with per-cpu data") Reported-by: syzbot+45b0c89a0fc7ae8dbadc(a)syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Tao Chen <chen.dylane(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20250513042747.757042-1-chen.dylane@linux.dev Closes: https://lore.kernel.org/bpf/8bc2554d-1052-4922-8832-e0078a033e1d@gmail.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 3827d4505af3..ad28507e16dc 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1604,7 +1604,7 @@ static struct pt_regs *get_bpf_raw_tp_regs(void) struct bpf_raw_tp_regs *tp_regs = this_cpu_ptr(&bpf_raw_tp_regs); int nest_level = this_cpu_inc_return(bpf_raw_tp_nest_level); - if (WARN_ON_ONCE(nest_level > ARRAY_SIZE(tp_regs->regs))) { + if (nest_level > ARRAY_SIZE(tp_regs->regs)) { this_cpu_dec(bpf_raw_tp_nest_level); return ERR_PTR(-EBUSY); } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] bpf: Fix WARN() in get_bpf_raw_tp_regs
by Pu Lehui 16 May '25

16 May '25

From: Tao Chen <chen.dylane(a)linux.dev> maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC8D46 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id… -------------------------------- syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first. Fixes: 9594dc3c7e71 ("bpf: fix nested bpf tracepoints with per-cpu data") Reported-by: syzbot+45b0c89a0fc7ae8dbadc(a)syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Tao Chen <chen.dylane(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20250513042747.757042-1-chen.dylane@linux.dev Closes: https://lore.kernel.org/bpf/8bc2554d-1052-4922-8832-e0078a033e1d@gmail.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index a266bfc8fcf6..a3444197d976 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -983,7 +983,7 @@ static struct pt_regs *get_bpf_raw_tp_regs(void) struct bpf_raw_tp_regs *tp_regs = this_cpu_ptr(&bpf_raw_tp_regs); int nest_level = this_cpu_inc_return(bpf_raw_tp_nest_level); - if (WARN_ON_ONCE(nest_level > ARRAY_SIZE(tp_regs->regs))) { + if (nest_level > ARRAY_SIZE(tp_regs->regs)) { this_cpu_dec(bpf_raw_tp_nest_level); return ERR_PTR(-EBUSY); } -- 2.34.1

2 1

[PATCH OLK-6.6] arm64/mpam: Add MPAM manual
by Zeng Heng 16 May '25

16 May '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC88OM -------------------------------- Add user manual for the MPAM features. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- Documentation/arch/arm64/mpam.md | 573 +++++++++++++++++++++++++++++++ 1 file changed, 573 insertions(+) create mode 100644 Documentation/arch/arm64/mpam.md diff --git a/Documentation/arch/arm64/mpam.md b/Documentation/arch/arm64/mpam.md new file mode 100644 index 000000000000..e469f62feb07 --- /dev/null +++ b/Documentation/arch/arm64/mpam.md @@ -0,0 +1,573 @@ +MPAM 用户手册 +========= + +# 1 MPAM 简介 + +MPAM（Memory system component Partioning and Monitoring）是Arm Architecture v8.4的拓展特性。用于解决服务器系统中，混合部署不同类型业务时，由于共享资源的竞争（L3/L2 Cache，MATA），而带来的关键应用性能下降或者系统整体性能下降问题。 + +MPAM的应用可针对不同业务，将同时作用于硬件访存路径上产生的竞争和冲突进行隔离控制，从而帮助提升服务器利用率，降低服务部署成本。 + +本手册只适用于OLK-6.6软件版本。 + +# 2 内核编译选项 + +配置 CONFIG_ARM64_MPAM=y 后，即使能MPAM完整功能。 + +# 3 内核启动参数 + +启动流程默认关闭MPAM，启动MPAM初始化需要**cmdline**添加**arm64.mpam**参数配置后重启机器。 + +# 3 接口总览 + +MPAM功能通过resctrl文件系统呈现，挂载点位于 */sys/fs/resctrl* 。系统启动后，需要手动挂载resctrl文件系统。 + +## 3.1 系统挂载参数 + +resctrl可以通过添加挂载参数支持多种挂载方式，具体指令如下： + +~~~ +# mount -t resctrl resctrl [-o cdp[,cdpl2][,debug][,l2]] /sys/fs/resctrl +~~~ + +挂载参数包括： + +* cdp: 针对L3缓存，根据访问指令和访问数据分别配置。 +* cdpl2: 针对L2缓存，根据访问指令和访问数据分别配置。 +* debug: 使能调试接口访问。 +* l2: 使能L2缓存配置和监控功能，默认关闭MPAM L2功能。 + +## 3.2 resctrl 系统目录介绍 + +### 3.2.1 Info 目录 + +Info 目录包含有关已启用资源的信息，每个资源都有其自己的子目录，子目录的名称反映了资源的名称。 + +每个子目录包含以下与分配相关的文件： + +缓存资源（L3/L2）子目录包含以下与分配相关的文件： + +**num_closids**: 适用于该资源的有效CLOSID（Class of Service ID）数量。内核会以所有已启用资源中最小的CLOSID数量作为限制。 + +**cbm_mask**: 适用于该资源的有效位掩码（bitmask）。 + +**min_cbm_bits**: 写入掩码时必须设置的连续位的最小数量。 + +**shareable_bits**: 与其他执行实体共享资源的位掩码。用户在设置独占缓存分区时可以使用此字段。 + +**bit_usage**: 标注了资源所有实例的使用情况的容量位掩码。说明如下： + + * *0*: 对应区域未使用。当系统的资源已被分配，且在“bit_usage”中发现“0”时，这表明资源被浪费了。 + + * *H*: 对应区域仅由硬件使用，但可供软件使用。如果资源的“shareable_bits”中有位被设置，但这些位并未全部出现在资源组的分配方案中，则“shareable_bits”中出现但未分配给资源组的位将被标记为“H”。 + + * *X*: 对应区域可供共享，并被硬件和软件使用。这些位同时出现在“shareable_bits”和资源组的分配中。 + + * *S*: 对应区域由软件使用，并可供共享。 + + * *E*: 对应区域被一个资源组独占使用，不允许共享。 + +**sparse_masks**: 指示是否支持CBM（Capacity Bit Mask）中的非连续1值。 + + * *0*: 仅支持CBM中的连续1值。 + + * *1*: 支持CBM中的非连续1值。 + +MB（Memory bandwidth，内存带宽）子目录包含以下与分配相关的文件： + +**min_bandwidth**: 用户可以请求的最小内存带宽百分比。 + +**bandwidth_gran**: 内存带宽百分比分配的粒度。分配的带宽百分比会四舍五入到硬件上可用的下一个控制步长。可用的带宽控制步长为： +~~~ +min_bandwidth + N * bandwidth_gran +~~~ + +**delay_linear**: 指示延迟刻度是线性还是非线性的。该字段仅用于信息参考。 + +如果支持监控功能，则会存在一个名为 L3_MON 和 MB_MON 的目录，其中包含以下文件： + +**num_rmids**: 可用的RMID（Resource Monitoring ID）数量。这是可以创建的“CTRL_MON”+“MON”组的最大数量。 + +**mon_features**: 如果为该资源启用了监控功能，则列出监控事件。例如： +~~~ +# grep . /sys/fs/resctrl/info/*_MON/mon_features +/sys/fs/resctrl/info/L3_MON/mon_features:llc_occupancy +/sys/fs/resctrl/info/MB_MON/mon_features:mbm_total_bytes +~~~ + +**max_threshold_occupancy**: 读/写文件，提供一个最大值（以字节为单位），低于此设定值下，之前使用过的LLC_occupancy计数器可以被考虑重新分配使用。 + +> 请注意，一旦释放了RMID（资源监控ID），它可能不会立即可用，因为RMID仍然与之前使用该RMID的缓存行相关联。因此，这些RMID会被放入一个“待定”列表中，并在缓存占用量降低后再次检查。如果系统中存在大量处于“待定”状态的RMID，但它们尚未准备好被使用，用户在执行mkdir操作时可能会看到-EBUSY错误。 + +> max_threshold_occupancy是一个用户可配置的值，用于确定在什么占用量下可以释放一个RMID。 + +最后，在 Info 目录的顶层有一个名为 **last_cmd_status** 的文件。每次通过文件系统发出“命令”（例如创建新目录或写入任何控制文件）时，该文件都会被重置。如果命令成功，文件内容将显示为“ok”。如果命令失败，它将提供比文件操作错误返回更详细的信息。例如： +~~~ +# echo "MB:1=110" > schemata +-bash: echo: write error: Invalid argument +# cat /sys/fs/resctrl/info/last_cmd_status +MB value 110 out of range [0,100] +~~~ + +### 3.2.2 资源分配和监控 + +资源组在resctrl文件系统中以目录的形式表示。默认组是根目录，刚挂载后，它拥有系统中的所有任务和CPU，并且可以充分利用所有资源。 + +在支持RDT（资源分配技术）控制功能的系统中，可以在根目录下创建额外的目录，这些目录指定了每种资源的不同数量（参见下面的“schemata”）。根目录和这些额外的顶级目录在下文中被称为“CTRL_MON”组。 + +在支持RDT监控的系统中，根目录和其他顶级目录中包含一个名为“mon_groups”的目录，在其中可以创建额外的目录来监控其父“CTRL_MON”组中任务的子集。这些在本文档的其余部分被称为“MON”组。 + +删除一个目录会将其所代表的组拥有的所有任务和CPU移动到其父目录。删除一个创建的“CTRL_MON”组将自动删除其下所有的“MON”组。 + +支持将“MON”组目录移动到一个新的父“CTRL_MON”组，以便在不影响其监控数据或分配的任务的情况下更改“MON”组的资源分配。此操作不适用于监控CPU的“MON”组。目前，除了简单地重命名“CTRL_MON”或“MON”组之外，不支持其他任何移动操作。 + +所有组包含以下文件： + +**tasks**: 读取此文件将显示属于该组的所有任务列表。将任务ID写入该文件会将任务添加到该组中。可以通过用逗号分隔任务ID来添加多个任务。任务将按顺序分配。在尝试分配任务时遇到的任何单个失败都会导致操作中止，而在失败之前已添加到组中的任务将保留在组中。失败信息将记录到/sys/fs/resctrl/info/last_cmd_status。 + +如果该组是一个“CTRL_MON”组，则任务将从之前拥有该任务的“CTRL_MON”组中移除，同时也会从任何拥有该任务的“MON”组中移除。如果该组是一个“MON”组，则任务必须已经属于该组的“CTRL_MON”父组。任务将从任何之前的“MON”组中移除。 + +**cpus**: 读取此文件将显示该组拥有的逻辑CPU的位掩码。将掩码写入该文件将向该组添加或移除CPU。与“tasks”文件类似，维护了一个层级结构，其中“MON”组只能包含其父“CTRL_MON”组拥有的CPU。 + +**cpus_list**: 与“cpus”类似，但使用CPU范围而不是位掩码。 + +当启用控制功能时，所有“CTRL_MON”组还将包含以下文件： + +**schemata**: 列出该组可用的所有资源。每种资源都有自己的行和格式——详细信息请参见下文。 + +**size**: 类似于“schemata”文件的显示，但显示的是每种资源分配的字节大小，而不是表示分配的位。 + +**mode**: 资源组的“mode”决定了其分配的共享方式。“shareable”资源组允许共享其分配，而“exclusive”资源组则不允许。 + +**ctrl_hw_id**: 仅在启用调试选项时可用。硬件用于控制组的标识符。在arm64架构上，即是 PARTID。 + +当启用监控功能时，所有“MON”组还将包含以下文件： + +**mon_data**: 包含一组按L3域和MB域事件组织的文件。例如，在具有两个L3域的系统中，将存在子目录“mon_L3_00”和“mon_L3_01”。 + +每个子目录中都有一个文件对应每个事件（例如“llc_occupancy”、“mbm_total_bytes”）。在“MON”组中，这些文件提供了组中所有任务的当前事件值。在“CTRL_MON”组中，这些文件提供了“CTRL_MON”组中所有任务以及所有“MON”组中任务的总和。有关使用方法的更多详细信息，请参见示例部分。 + +**mon_hw_id**: 仅在启用调试选项时可用。硬件用于监控组的标识符。 + +以下为resctrl文件系统目录树： + +~~~ +/sys/fs/resctrl(根分组) + ├── cpus # bitmask方式显示根分组关联的vcpu + ├── cpus_list # cpu list方式显示根分组关联的vcpu + ├── ctrl_hw_id # 硬件用于控制组的标识符 + ├── info # 用于显示属性信息及错误提示信息 + │ ├── L3 + │ │ ├── bit_usage # 标注了资源所有实例的使用情况的容量位掩码 + │ │ ├── cbm_mask # 系统所支持的最大cache way bitmask，一个bit代表一个cache way + │ │ ├── min_cbm_bits # 使用schemata所能配置的最小cache way bitmask + │ │ ├── num_closids # L3能够提供创建控制组的最大数量 + │ │ ├── shareable_bits # 当前所有cbm_mask全部shareable，支持后续扩展 + │ │ └── sparse_masks # 指示是否支持CBM（Capacity Bit Mask）中的非连续1值 + │ ├── L3_MON + │ │ ├── max_threshold_occupancy # 低于此设定值下，之前使用过的LLC_occupancy计数器可以被考虑重新分配使用 + │ │ ├── mon_features # 列出监控事件 + │ │ └── num_rmids # 可创建控制组和监控组的总数 + │ ├── last_cmd_status # 操作错误提示 + │ ├── MB + │ │ ├── bandwidth_gran # 带宽百分比配置粒度 + │ │ ├── delay_linear # 指示延迟刻度是线性还是非线性的 + │ │ ├── min_bandwidth # 最小带宽配置百分比 + │ │ └── num_closids # 同L3 num_closid + │ └── MB_MON + │ ├── mon_features # 同L3 mon_features + │ └── num_rmids # 同L3 num_rmids + ├── mode # 资源组的 mode 决定了其分配的共享方式 + ├── mon_data + │ ├── mon_L3_01 # 标号代表L3 cache id + │ │ └── llc_occupancy # 表示当前分组所关联的pid/vcpu在该区域上实际占用L3 Cache大小，下同 + │ ├── mon_L3_122 + │ │ └── llc_occupancy + │ ├── mon_MB_00 # 标号代表numa id + │ │ └── mbm_total_bytes # 表示当前分组所关联的pid/vcpu在该区域上内存带宽流量大小，下同 + │ └── mon_MB_01 + │ └── mbm_total_bytes + ├── mon_groups # 创建监控组目录 + ├── mon_hw_id # 硬件用于监控组的标识符 + ├── schemata # 资源使用配置接口 + ├── size # 显示的是每种资源分配的字节大小 + └── tasks # 显示与根组关联的pid +~~~ + +### 3.2.3 控制组配置接口 Schemata 文件 + +**schemata**文件中的每一行描述一种资源。每行以资源的名称开头，后面跟着该资源在系统中每个实例上要应用的具体值。 + +#### Cache IDs + +在当前一代的系统中，每个插槽（socket）有一个L3缓存，而L2缓存通常仅由一个核心上的超线程共享，但这并不是架构上的强制要求。我们可能会在一个插槽上有多个独立的L3缓存，或者多个核心共享一个L2缓存。因此，我们不使用“插槽”或“核心”来定义共享资源的逻辑CPU集合，而是使用“Cache ID”（缓存ID）。 + +在给定的缓存级别上，这将在整个系统中是一个唯一的数字（但不能保证是一个连续的序列，可能会有间隔）。要查找每个逻辑CPU的ID，请查看 /sys/devices/system/cpu/cpu*/cache/index*/id。 + +#### Cache Bit Masks（CBM，缓存位掩码） + +对于缓存资源，我们使用位掩码来描述可用于分配的缓存部分。掩码的最大值由每种CPU型号定义（并且可能因不同的缓存级别而异）。该值在resctrl文件系统的“info”目录中提供，位于info/{resource}/cbm_mask。 + +#### L3 缓存配置 + +当未启用CDP（代码/数据缓存划分）时，L3 schemata的格式为： + +~~~ +L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +~~~ + +当启用CDP时，L3控制被拆分为两个独立的资源，因此您可以分别为代码和数据指定独立的掩码，如下所示： + +~~~ +L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +~~~ + +读取schemata文件将显示所有域上所有资源的状态。在写入时，您只需要指定您希望更改的值。 + +例如使用默认方式挂载，设置L3缓存位掩码只有4位： + +~~~ +# mount -t resctrl resctrl /sys/fs/resctrl/ +# cat /sys/fs/resctrl/schemata +L3:1=fffffff;122=fffffff + +# echo "L3:122=3c0;" > /sys/fs/resctrl/schemata +# cat /sys/fs/resctrl/schemata +L3:1=fffffff;122=00003c0 +~~~ + +使用开启CDP方式挂载，设置L3 data缓存位掩码只有4位： + +~~~ +# mount -t resctrl resctrl /sys/fs/resctrl/ -o cdp +# cat /sys/fs/resctrl/schemata +L3DATA:1=fffffff;122=fffffff +L3CODE:1=fffffff;122=fffffff + +# echo "L3DATA:122=3c0;" > schemata +# cat /sys/fs/resctrl/schemata +L3DATA:1=fffffff;122=00003c0 +L3CODE:1=fffffff;122=fffffff +~~~ + +#### L2 缓存配置 + +L2 缓存配置功能默认关闭，需要通过显式添加 l2 挂载参数，才会使能L2缓存配置功能。使能L2功能以后，系统关闭 cpuidle powerdown 功能和cpu下线功能。 + +L2 schemata的格式是： + +~~~ +L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +~~~ + +使用“cdpl2”挂载选项可以在L2上支持CDP： + +~~~ +L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;... +~~~ + +L2 缓存配置示例，设置L2缓存位掩码只有4位： + +~~~ +# mount -t resctrl resctrl /sys/fs/resctrl/ -o l2 +# cat schemata +L2:4=000ff;8=000ff + +# echo "L2:4=f;" > schemata +# cat schemata +L2:4=0000f;8=000ff +~~~ + +使用“cdpl2”挂载选项： + +~~~ +# mount -t resctrl resctrl /sys/fs/resctrl/ -o l2cdp,l2 +# cat schemata +L2DATA:4=000ff;8=000ff +L2CODE:4=000ff;8=000ff + +# echo "L2DATA:4=f;" > schemata +# cat schemata +L2DATA:4=0000f;8=000ff # 控制组 L2 DATA 只能使用L2 cache4的4个cache way +L2CODE:4=000ff;8=000ff +~~~ + +#### MB 内存带宽分配 + +对于内存带宽资源，默认情况下，用户通过指定总内存带宽的百分比来控制该资源。 + +每种CPU型号的最小带宽百分比值是预定义的，可以通过info/MB/min_bandwidth查询。分配的带宽粒度也取决于CPU型号，可以在info/MB/bandwidth_gran中查询。可用的带宽控制步长为：min_bw + N * bw_gran。中间值会被四舍五入到硬件上可用的下一个控制步长。 + +MB schemata的格式是： + +~~~ +MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;... +~~~ + +MB 带宽配置示例： + +~~~ +# cat /sys/fs/resctrl/schemata +MB:0=0000100;1=0000100 + +# echo "MB:0=50" > /sys/fs/resctrl/schemata +# cat /sys/fs/resctrl/schemata +MB:0=0000050;1=0000100 # 降低控制组 MB 内存带宽使用上限为50% +~~~ + +### 3.2.4 资源分配规则 + +当一个任务正在运行时，以下规则定义了它可用的资源： +1. 如果任务属于一个非默认组，则使用该组的分配方案（schemata）。 +2. 否则，如果任务属于默认组，但运行在一个被分配给某个特定组的CPU上，则使用该CPU所属组的分配方案。 +3. 否则，使用默认组的分配方案。 + +### 3.2.5 监控组配置方法 + +读取控制组和监控组的监控数据，可通过 mon_data 目录接口读取监控数据： + +~~~ +# grep . mon_data/*/* +mon_data/mon_L3_01/llc_occupancy:73276416 +mon_data/mon_L3_122/llc_occupancy:11875328 +mon_data/mon_MB_00/mbm_total_bytes:32806 +mon_data/mon_MB_01/mbm_total_bytes:31700 +~~~ + +其中，mon_data读取监控数据文件分别： + * llc_occupancy 代表 L3缓存当前占用量，单位 Byte + * mbm_total_bytes 代表内存带宽瞬时流量，单位 MB/s + +支持在控制组下创建子监控组，监控父控制组监控对象的子集： + +~~~ +# cd /sys/fs/resctrl/p1 +# cd mon_groups/ && mkdir m1 # 监控组只能监控，m1分组资源配置跟随p1分组 +# echo '0-1' > cpus_list +# grep . mon_data/mon_*/* +mon_data/mon_L3_01/llc_occupancy:18432 +mon_data/mon_L3_122/llc_occupancy:1024 +mon_data/mon_MB_00/mbm_total_bytes:0 +mon_data/mon_MB_01/mbm_total_bytes:0 +~~~ + +控制组监控的是控制组本身及所有子监控组的监控值之和。 + +## 3.3 QoS 增强特性 + +### 3.3.1 PRI 优先级设置 + +对共享资源优先级进行配置，包括 L3PRI 和 MBPRI： + +~~~ +# cat schemata + MBPRI:0=0000007;1=0000007 + L3PRI:1=0000003;122=0000003 + +# echo "MBPRI:0=0000003" > schemata +# cat schemata + MBPRI:0=0000003;1=0000007 # 降低控制组 MB numa0的优先级 + L3PRI:1=0000003;122=0000003 + +# echo "MBPRI:0=0000003" > schemata + +~~~ + +优先级设置数字越大，即优先级越高，反之，数字越小，优先级越低。 + +### 3.3.2 MIN 优先级设置 + +共享资源实际使用占比低于设置值，会自动提高对该资源使用优先级，包括 L3MIN 和 MBMIN： + +~~~ +# cat schemata + MBMIN:0=00100 + L3MIN:1=00100;5=00100 + +# echo "MBMIN:0=00050" > schemata +# cat schemata + MBMIN:0=00050 + L3MIN:1=00100;5=00100 + +# echo "L3MIN:1=00050" > schemata +# cat schemata + MBMIN:0=00050 + L3MIN:1=00050;5=00100 +~~~ + +L3MIN 和 MBMIN 接口接受的输入参数为百分比，即设置值与总资源（内存带宽/缓存占用量）的占比。 + +### 3.3.3 HDL 强制限制设置 + +当MBHDL=1，限制MB共享资源使用量不能超出MB设置值，若MBHDL=0，则允许空闲情况下，MB共享资源使用量超过MB设置值： + +~~~ +# cat schemata + MBHDL:0=0000001;1=0000001 + +# echo "MBHDL:0=0000000" > schemata +# cat schemata + MBHDL:0=0000000;1=0000001 # 关闭MB在numa0上的强制限制功能 +~~~ + +### 3.3.4 MAX 资源上限设置 + +设置允许分配的缓存容量的最大百分比，包括 L3MAX 接口： + +~~~ +# cat schemata + L3MAX:1=00100;5=00100 + +# echo "L3MAX:1=00050" > schemata +# cat schemata + L3MAX:1=00050;5=00100 # 降低L3分配的缓存最大容量百分比 +~~~ + +## 3.4 外设 IO 流量管控 + +MPAM 提供通过绑定 iommu_group ID，对设备IO流量进行带宽限制和监控。 + +譬如，控制网卡设备 eno2 ，首先查找该设备 PCI_SLOT 信息： + +~~~ +# cat /sys/class/net/eno2/device/uevent | grep PCI_SLOT +PCI_SLOT_NAME=0000:35:00.1 +~~~ + +或者通过 ethtool 工具查看 bus-info 信息： + +~~~ +# ethtool -i eno2 | grep bus-info +bus-info: 0000:35:00.1 +~~~ + +按照设备总线信息，查找到该设备所属的 iommu_group ： + +~~~ +# find /sys/kernel/iommu_groups/ -name "0000:35:00.1" +/sys/kernel/iommu_groups/17/devices/0000:35:00.1 +~~~ + +或者通过 lspci 工具查看 iommu_group 信息： + +~~~ +# lspci -vvv -s 0000:35:00.1 | grep "IOMMU group" + IOMMU group: 17 +~~~ + +将查询到的group id 17，通过 tasks 接口绑定到指定的控制组下： + +~~~ +# cd /sys/fs/resctrl/p1/ +# echo "iommu_group:17" > tasks +# cat tasks +iommu_group:17 # 此时iommu_group 17 已被绑定到控制组p1 +~~~ + +此时可以查看设备流量： + +~~~ +# grep . mon_data/mon_MB_0*/* +mon_data/mon_MB_00/mbm_total_bytes:0 +mon_data/mon_MB_01/mbm_total_bytes:4230 +~~~ + +通过MB配置，限制该设备的流量带宽： + +~~~ +# echo "MB:1=0000001" > schemata +# cat schemata + MB:0=0000100;1=0000000 + +# grep . mon_data/*/* +mon_data/mon_MB_00/mbm_total_bytes:0 +mon_data/mon_MB_01/mbm_total_bytes:1208 +~~~ + +# 4 控制组和监控组配置使用示例 + +/sys/fs/resctrl 默认为根分组，根分组可以创建若干个控制组，一个控制组既可以关联一组pid/tid，也可以关联一组cpu集合。 + +创建一个新的控制组，关联 pid/tid： + +~~~ +# cd /sys/fs/resctrl/ && mkdir p1 +# cd p1 && echo $$ > tasks # 关联当前shell进程pid到p1组 +# cat tasks # 可查看成功关联的pid +29190 +29607 +~~~ + +也可以选择关联 cpu： + +~~~ +# cd p1 && echo '0-1' > cpus_list +# cat cpus_list # 可查看关联的cpu +0-1 +~~~ + +查看可创建的控制组和监控组数量： + +~~~ +# cat info/L3/num_closids # 可在info对应的资源的目录下查看closid数量，即可以创建控制组的数量 +32 +# cat info/MB/num_closids +32 +# cat info/L3_MON/num_rmids # 可以创建控制组和监控组的总数量 +128 +# cat info/MB_MON/num_rmids +128 +~~~ + +通过配置控制组可达到隔离 L3 Cache/Memory Bandwidth 效果，通过读取对应分组mon_data接口可以获取该组资源占用情况，比如对一个控制组限制L3 Cache使用： + +~~~ +# cat info/L3/cbm_mask # 查看info目录下对应资源的属性 +fffffff +# cat info/L3/min_cbm_bits +1 + +# cd /sys/fs/resctrl/p1 +# cat schemata + MB:0=0000100;1=0000100 + L3:1=fffffff;122=fffffff + +# echo 'L3:0=1' > schemata # 配置1条cache way给p1分组 +# cat schemata + MB:0=0000100;1=0000100 # 若此时该组关联pid/cpu，那么该pid/cpu产生的访存请求只会分配到这条cache + L3:1=0000001;122=fffffff +~~~ + +对控制组限制MB使用： + +~~~ +# cat info/MB/min_bandwidth # 和配置L3类似，也可以查看MB的相关信息 +1 +# cat info/MB/bandwidth_gran +1 # 可知，配置带宽最小百分比是1%，颗粒度是1% +# cat schemata + MB:0=0000100;1=0000100 + L3:1=0000001;122=fffffff +# echo 'MB:0=1' > schemata +# cat schemata + MB:0=0000001;1=0000100 + L3:1=0000001;122=fffffff +~~~ + +支持在控制组下创建子监控组： + +~~~ +# cd /sys/fs/resctrl/p1 +# cd mon_groups/ && mkdir m1 # 监控组只能监控，m1分组资源配置跟随p1分组 +# ls m1/ +cpus cpus_list mon_data tasks +# echo '0-1' > cpus_list +# cat cpus_list +0-1 +# grep . mon_data/mon_*/* +mon_data/mon_L3_01/llc_occupancy:18432 +mon_data/mon_L3_122/llc_occupancy:1024 +mon_data/mon_MB_00/mbm_total_bytes:0 +mon_data/mon_MB_01/mbm_total_bytes:0 +~~~ -- 2.25.1

2 1

[PATCH OLK-5.10] bpf: Fix kmemleak warning for percpu hashmap
by Pu Lehui 16 May '25

16 May '25

From: Yonghong Song <yonghong.song(a)linux.dev> mainline inclusion from mainline-v6.15-rc1 commit 11ba7ce076e5903e7bdc1fd1498979c331b3c286 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6BRF CVE: CVE-2025-37807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported. Reported-by: Vlad Poenaru <thevlad(a)meta.com> Signed-off-by: Yonghong Song <yonghong.song(a)linux.dev> Acked-by: Martin KaFai Lau <martin.lau(a)kernel.org> Link: https://lore.kernel.org/r/20250224175514.2207227-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Conflicts: kernel/bpf/hashtab.c [The conflicts were due to not merge commit 0b56e637f7058] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/hashtab.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 72bc5f575254..52985f71bb8c 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -184,12 +184,12 @@ static bool htab_is_percpu(const struct bpf_htab *htab) static inline void htab_elem_set_ptr(struct htab_elem *l, u32 key_size, void __percpu *pptr) { - *(void __percpu **)(l->key + key_size) = pptr; + *(void __percpu **)(l->key + roundup(key_size, 8)) = pptr; } static inline void __percpu *htab_elem_get_ptr(struct htab_elem *l, u32 key_size) { - return *(void __percpu **)(l->key + key_size); + return *(void __percpu **)(l->key + roundup(key_size, 8)); } static void *fd_htab_map_get_ptr(const struct bpf_map *map, struct htab_elem *l) -- 2.34.1

2 1

[PATCH OLK-6.6 v2 00/11] IPIV-BUGFIX for HIP12
by Jinqian Yang 16 May '25

16 May '25

Compared with the previous IPIV, the IPIV-BUGFIX has the following changes: 1. Use Kconfig to Control whether to enable IPIV. 2. Users use ioctl to control whether to enable IPIV. 3. Use the SMCCC interface for Guest OS to control whether to enable IPIV. 4. ensure that enable_ipiv_from_guest are the same before and after live migration 4. make sure vcpu_id == vcpu_idx. 5. the MPIDR cannot be changed When IPIV is enabled. 6. fix bug that ipiv enable is displayed on the host when "kvm-arm.vgic_v4_enable=0 kvm-arm.ipiv_enabled=1" is configured. 7. Add Exception Printing Jinqian Yang (5): arm64/config: add config to control whether enable IPIV feature KVM: arm64: fix live migration bug of IPIv KVM: arm64: using kvm_vgic_global_state for ipiv kvm: hisi: print error for IPIV arm64/kabi: use KABI_EXTEND to skip KABI check Zhou Wang (6): KVM: arm64: Introduce ipiv enable ioctl KVM: arm64: Document PV-sgi interface KVM: arm64: Implement PV_SGI related calls irqchip/gic: Add HiSilicon PV SGI support kvm: hisi: make sure vcpu_id and vcpu_idx have same value in IPIv kvm: hisi: Don't allow to change mpidr in IPIv Documentation/virt/kvm/arm/hypercalls.rst | 4 ++ Documentation/virt/kvm/arm/pvsgi.rst | 33 ++++++++++++++ arch/arm64/Kconfig | 13 ++++++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/include/uapi/asm/kvm.h | 5 +++ arch/arm64/kvm/arm.c | 34 ++++++++++---- arch/arm64/kvm/hisilicon/hisi_virt.c | 32 ++++++++++++- arch/arm64/kvm/hisilicon/hisi_virt.h | 20 +++++++-- arch/arm64/kvm/hypercalls.c | 26 +++++++++++ arch/arm64/kvm/sys_regs.c | 34 +++++++++----- arch/arm64/kvm/vgic/vgic-init.c | 42 ++++++++++++++--- arch/arm64/kvm/vgic/vgic-its.c | 17 +++++++ arch/arm64/kvm/vgic/vgic-mmio-v3.c | 1 - drivers/irqchip/irq-gic-v3-its.c | 50 ++++++++++++++------- drivers/irqchip/irq-gic-v3.c | 55 ++++++++++++++++++----- include/linux/arm-smccc.h | 15 +++++++ include/linux/irqchip/arm-gic-v3.h | 10 +++++ include/linux/irqchip/arm-gic-v4.h | 5 ++- 19 files changed, 344 insertions(+), 56 deletions(-) create mode 100644 Documentation/virt/kvm/arm/pvsgi.rst -- 2.33.0

2 12

[PATCH OLK-6.6 0/6] LoongArch: add PCA953X/2K3000 GMAC/IGC netcard/NR_CPUS=2048/SCHED_MC support
by Hongchen Zhang 16 May '25

16 May '25

Tianyang Zhang (2): LoongArch: Prevent cond_resched() occurring within kernel-fpu LoongArch: Add SCHED_MC (Multi-core scheduler) support wanghongliang (4): LoongArch: CONFIG_NR_CPUS expanded to 2048 LoongArch: Enable IGC driver LoongArch: Enable GPIO_PCA953X driver LoongArch: 2K3000 GMAC support. arch/loongarch/Kconfig | 16 ++- arch/loongarch/configs/loongson3_defconfig | 3 +- arch/loongarch/include/asm/smp.h | 1 + arch/loongarch/include/asm/topology.h | 9 ++ arch/loongarch/kernel/kfpu.c | 22 ++++- arch/loongarch/kernel/smp.c | 38 +++++++ .../ethernet/stmicro/stmmac/dwmac-loongson.c | 98 +++++++++++-------- 7 files changed, 141 insertions(+), 46 deletions(-) -- 2.33.0

2 7

[PATCH OLK-6.6] PCI: Fix reference leak in pci_register_host_bridge()
by Qi Xi 16 May '25

16 May '25

From: Ma Ke <make24(a)iscas.ac.cn> mainline inclusion from mainline-v6.15-rc1 commit 804443c1f27883926de94c849d91f5b7d7d696e9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6M6P CVE: CVE-2025-37836 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. Link: https://lore.kernel.org/r/20250225021440.3130264-1-make24@iscas.ac.cn Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.moun…] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/pci/probe.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index c879d88807e7..529c75b097f5 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -886,6 +886,7 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) resource_size_t offset, next_offset; LIST_HEAD(resources); struct resource *res, *next_res; + bool bus_registered = false; char addr[64], *fmt; const char *name; int err; @@ -951,6 +952,7 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) name = dev_name(&bus->dev); err = device_register(&bus->dev); + bus_registered = true; if (err) goto unregister; @@ -1034,12 +1036,15 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) unregister: put_device(&bridge->dev); device_del(&bridge->dev); - free: #ifdef CONFIG_PCI_DOMAINS_GENERIC pci_bus_release_domain_nr(bus, parent); #endif - kfree(bus); + if (bus_registered) + put_device(&bus->dev); + else + kfree(bus); + return err; } -- 2.33.0

2 1

[PATCH OLK-6.6] PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
by Qi Xi 16 May '25

16 May '25

From: Ryo Takakura <ryotkkr98(a)gmail.com> mainline inclusion from mainline-v6.15-rc1 commit 18056a48669a040bef491e63b25896561ee14d90 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC5BIT CVE: CVE-2025-23161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose. A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock. Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled. This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 Signed-off-by: Ryo Takakura <ryotkkr98(a)gmail.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv(a)redhat.com> Acked-by: Luis Claudio R. Goncalves <lgoncalv(a)redhat.com> [bigeasy: reword commit message] Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Tested-off-by: Luis Claudio R. Goncalves <lgoncalv(a)redhat.com> Link: https://lore.kernel.org/r/20250218080830.ufw3IgyX@linutronix.de [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/pci/controller/vmd.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 5ff2066aa516..dfa222e02c4d 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -125,7 +125,7 @@ struct vmd_irq_list { struct vmd_dev { struct pci_dev *dev; - spinlock_t cfg_lock; + raw_spinlock_t cfg_lock; void __iomem *cfgbar; int msix_count; @@ -402,7 +402,7 @@ static int vmd_pci_read(struct pci_bus *bus, unsigned int devfn, int reg, if (!addr) return -EFAULT; - spin_lock_irqsave(&vmd->cfg_lock, flags); + raw_spin_lock_irqsave(&vmd->cfg_lock, flags); switch (len) { case 1: *value = readb(addr); @@ -417,7 +417,7 @@ static int vmd_pci_read(struct pci_bus *bus, unsigned int devfn, int reg, ret = -EINVAL; break; } - spin_unlock_irqrestore(&vmd->cfg_lock, flags); + raw_spin_unlock_irqrestore(&vmd->cfg_lock, flags); return ret; } @@ -437,7 +437,7 @@ static int vmd_pci_write(struct pci_bus *bus, unsigned int devfn, int reg, if (!addr) return -EFAULT; - spin_lock_irqsave(&vmd->cfg_lock, flags); + raw_spin_lock_irqsave(&vmd->cfg_lock, flags); switch (len) { case 1: writeb(value, addr); @@ -455,7 +455,7 @@ static int vmd_pci_write(struct pci_bus *bus, unsigned int devfn, int reg, ret = -EINVAL; break; } - spin_unlock_irqrestore(&vmd->cfg_lock, flags); + raw_spin_unlock_irqrestore(&vmd->cfg_lock, flags); return ret; } @@ -1020,7 +1020,7 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id) if (features & VMD_FEAT_OFFSET_FIRST_VECTOR) vmd->first_vec = 1; - spin_lock_init(&vmd->cfg_lock); + raw_spin_lock_init(&vmd->cfg_lock); pci_set_drvdata(dev, vmd); err = vmd_enable_domain(vmd, features); if (err) -- 2.33.0

2 1

[PATCH OLK-6.6] [Backport] kernel: Remove signal hacks for vhost_tasks
by Liu Kai 16 May '25

16 May '25

From: Mike Christie <michael.christie(a)oracle.com> mainline inclusion from mainline-v6.10-rc1 commit 240a1853b4d2bce51e5cac9ba65cd646152ab6d6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC7LWK Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This removes the signal/coredump hacks added for vhost_tasks in: Commit f9010dbdce91 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression") When that patch was added vhost_tasks did not handle SIGKILL and would try to ignore/clear the signal and continue on until the device's close function was called. In the previous patches vhost_tasks and the vhost drivers were converted to support SIGKILL by cleaning themselves up and exiting. The hacks are no longer needed so this removes them. Signed-off-by: Mike Christie <michael.christie(a)oracle.com> Message-Id: <20240316004707.45557-10-michael.christie(a)oracle.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Liu Kai <liukai284(a)huawei.com> --- fs/coredump.c | 4 +--- kernel/exit.c | 5 +---- kernel/signal.c | 4 +--- 3 files changed, 3 insertions(+), 10 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index 9d235fa14ab98..ead3b05fb8f48 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -371,9 +371,7 @@ static int zap_process(struct task_struct *start, int exit_code) if (t != current && !(t->flags & PF_POSTCOREDUMP)) { sigaddset(&t->pending.signal, SIGKILL); signal_wake_up(t, 1); - /* The vhost_worker does not particpate in coredumps */ - if ((t->flags & (PF_USER_WORKER | PF_IO_WORKER)) != PF_USER_WORKER) - nr++; + nr++; } } diff --git a/kernel/exit.c b/kernel/exit.c index 3540b2c9b1b6a..f2b87b2a70098 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -411,10 +411,7 @@ static void coredump_task_exit(struct task_struct *tsk) tsk->flags |= PF_POSTCOREDUMP; core_state = tsk->signal->core_state; spin_unlock_irq(&tsk->sighand->siglock); - - /* The vhost_worker does not particpate in coredumps */ - if (core_state && - ((tsk->flags & (PF_IO_WORKER | PF_USER_WORKER)) != PF_USER_WORKER)) { + if (core_state) { struct core_thread self; self.task = current; diff --git a/kernel/signal.c b/kernel/signal.c index c73873d67a63f..3ccbc61a1f09b 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1388,9 +1388,7 @@ int zap_other_threads(struct task_struct *p) while_each_thread(p, t) { task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK); - /* Don't require de_thread to wait for the vhost_worker */ - if ((t->flags & (PF_IO_WORKER | PF_USER_WORKER)) != PF_USER_WORKER) - count++; + count++; /* Don't bother with already dead threads */ if (t->exit_state) -- 2.34.1

2 1