- Kernel - mailweb.openeuler.org

[PATCH] perf: Fix hang while freeing sigtrap event
by Luo Gengkun 29 May '25

29 May '25

From: Frederic Weisbecker <frederic(a)kernel.org> mainline inclusion from mainline-v6.15-rc2 commit 56799bc035658738f362acec3e7647bb84e68933 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC5BL4 CVE: CVE-2025-37747 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job. Reported-by: "Yi Lai" <yi1.lai(a)linux.intel.com> Closes: https://lore.kernel.org/all/Zx9Losv4YcJowaP%2F@ly-workstation/ Reported-by: syzbot+3c4321e10eea460eb606(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/673adf75.050a0220.87769.0024.GAE@google.com/ Fixes: 3a5465418f5f ("perf: Fix event leak upon exec and file release") Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20250304135446.18905-1-frederic@kernel.org Conflicts: kernel/events/core.c include/linux/perf_event.h [To apply this mainline patch, first revert the 008ebcfec23d ("[Huawei] perf: Fix kabi broken of struct perf_event"). Then pick mainline patch 16b9569df9d2 ("perf: Don't disable preemption in perf_pending_task()."). Finally, pick this fix patch and resolve conflicts and merged all patch together.] Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- include/linux/perf_event.h | 2 +- kernel/events/core.c | 65 +++++++++++--------------------------- 2 files changed, 19 insertions(+), 48 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 420f15ddce39..826fb16906fe 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -851,7 +851,7 @@ struct perf_event { */ __u32 orig_type; - KABI_USE(1, struct rcuwait pending_work_wait) + KABI_RESERVE(1) KABI_RESERVE(2) KABI_RESERVE(3) KABI_RESERVE(4) diff --git a/kernel/events/core.c b/kernel/events/core.c index 69cdf8aabf52..f042d6101932 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -2294,6 +2294,7 @@ event_sched_out(struct perf_event *event, struct perf_event_context *ctx) !event->pending_work && !task_work_add(current, &event->pending_task, TWA_RESUME)) { event->pending_work = 1; + WARN_ON_ONCE(!atomic_long_inc_not_zero(&event->refcount)); } else { local_dec(&event->ctx->nr_pending); } @@ -5187,35 +5188,9 @@ static bool exclusive_event_installable(struct perf_event *event, static void perf_addr_filters_splice(struct perf_event *event, struct list_head *head); -static void perf_pending_task_sync(struct perf_event *event) -{ - struct callback_head *head = &event->pending_task; - - if (!event->pending_work) - return; - /* - * If the task is queued to the current task's queue, we - * obviously can't wait for it to complete. Simply cancel it. - */ - if (task_work_cancel(current, head)) { - event->pending_work = 0; - local_dec(&event->ctx->nr_pending); - return; - } - - /* - * All accesses related to the event are within the same - * non-preemptible section in perf_pending_task(). The RCU - * grace period before the event is freed will make sure all - * those accesses are complete by then. - */ - rcuwait_wait_event(&event->pending_work_wait, !event->pending_work, TASK_UNINTERRUPTIBLE); -} - static void _free_event(struct perf_event *event) { irq_work_sync(&event->pending_irq); - perf_pending_task_sync(event); unaccount_event(event); @@ -5340,10 +5315,17 @@ static void perf_remove_from_owner(struct perf_event *event) static void put_event(struct perf_event *event) { + struct perf_event *parent; + if (!atomic_long_dec_and_test(&event->refcount)) return; + parent = event->parent; _free_event(event); + + /* Matches the refcount bump in inherit_event() */ + if (parent) + put_event(parent); } /* @@ -5427,11 +5409,6 @@ int perf_event_release_kernel(struct perf_event *event) if (tmp == child) { perf_remove_from_context(child, DETACH_GROUP); list_move(&child->child_list, &free_list); - /* - * This matches the refcount bump in inherit_event(); - * this can't be the last reference. - */ - put_event(event); } else { var = &ctx->refcount; } @@ -5457,7 +5434,8 @@ int perf_event_release_kernel(struct perf_event *event) void *var = &child->ctx->refcount; list_del(&child->child_list); - free_event(child); + /* Last reference unless ->pending_task work is pending */ + put_event(child); /* * Wake any perf_event_free_task() waiting for this event to be @@ -5468,7 +5446,11 @@ int perf_event_release_kernel(struct perf_event *event) } no_ctx: - put_event(event); /* Must be the 'last' reference */ + /* + * Last reference unless ->pending_task work is pending on this event + * or any of its children. + */ + put_event(event); return 0; } EXPORT_SYMBOL_GPL(perf_event_release_kernel); @@ -6857,12 +6839,6 @@ static void perf_pending_task(struct callback_head *head) struct perf_event *event = container_of(head, struct perf_event, pending_task); int rctx; - /* - * All accesses to the event must belong to the same implicit RCU read-side - * critical section as the ->pending_work reset. See comment in - * perf_pending_task_sync(). - */ - preempt_disable_notrace(); /* * If we 'fail' here, that's OK, it means recursion is already disabled * and we won't recurse 'further'. @@ -6873,12 +6849,11 @@ static void perf_pending_task(struct callback_head *head) event->pending_work = 0; perf_sigtrap(event); local_dec(&event->ctx->nr_pending); - rcuwait_wake_up(&event->pending_work_wait); } + put_event(event); if (rctx >= 0) perf_swevent_put_recursion_context(rctx); - preempt_enable_notrace(); } #ifdef CONFIG_GUEST_PERF_EVENTS @@ -11990,7 +11965,6 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu, init_waitqueue_head(&event->waitq); init_irq_work(&event->pending_irq, perf_pending_irq); init_task_work(&event->pending_task, perf_pending_task); - rcuwait_init(&event->pending_work_wait); mutex_init(&event->mmap_mutex); raw_spin_lock_init(&event->addr_filters.lock); @@ -13143,8 +13117,7 @@ perf_event_exit_event(struct perf_event *event, struct perf_event_context *ctx) * Kick perf_poll() for is_event_hup(); */ perf_event_wakeup(parent_event); - free_event(event); - put_event(parent_event); + put_event(event); return; } @@ -13262,13 +13235,11 @@ static void perf_free_event(struct perf_event *event, list_del_init(&event->child_list); mutex_unlock(&parent->child_mutex); - put_event(parent); - raw_spin_lock_irq(&ctx->lock); perf_group_detach(event); list_del_event(event, ctx); raw_spin_unlock_irq(&ctx->lock); - free_event(event); + put_event(event); } /* -- 2.34.1

1 0

[PATCH openEuler-1.0-LTS] memcg: always call cond_resched() after fn()
by Chen Ridong 29 May '25

29 May '25

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.15-rc1 commit 06717a7b6c86514dbd6ab322e8083ffaa4db5712 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBE42N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- I am seeing soft lockup on certain machine types when a cgroup OOMs. This is happening because killing the process in certain machine might be very slow, which causes the soft lockup and RCU stalls. This happens usually when the cgroup has MANY processes and memory.oom.group is set. Example I am seeing in real production: [462012.244552] Memory cgroup out of memory: Killed process 3370438 (crosvm) .... .... [462037.318059] Memory cgroup out of memory: Killed process 4171372 (adb) .... [462037.348314] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [stat_manager-ag:1618982] .... Quick look at why this is so slow, it seems to be related to serial flush for certain machine types. For all the crashes I saw, the target CPU was at console_flush_all(). In the case above, there are thousands of processes in the cgroup, and it is soft locking up before it reaches the 1024 limit in the code (which would call the cond_resched()). So, cond_resched() in 1024 blocks is not sufficient. Remove the counter-based conditional rescheduling logic and call cond_resched() unconditionally after each task iteration, after fn() is called. This avoids the lockup independently of how slow fn() is. Link: https://lkml.kernel.org/r/20250523-memcg_fix-v1-1-ad3eafb60477@debian.org Fixes: ade81479c7dd ("memcg: fix soft lockup in the OOM process") Signed-off-by: Breno Leitao <leitao(a)debian.org> Suggested-by: Rik van Riel <riel(a)surriel.com> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Michael van der Westhuizen <rmikey(a)meta.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Cc: Pavel Begunkov <asml.silence(a)gmail.com> Cc: Chen Ridong <chenridong(a)huawei.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/memcontrol.c [context is mispatched] Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- mm/memcontrol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index a35b94cacada..b9d083303cf6 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1230,7 +1230,6 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg, { struct mem_cgroup *iter; int ret = 0; - int i = 0; BUG_ON(memcg == root_mem_cgroup); @@ -1240,10 +1239,9 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg, css_task_iter_start(&iter->css, CSS_TASK_ITER_PROCS, &it); while (!ret && (task = css_task_iter_next(&it))) { - /* Avoid potential softlockup warning */ - if ((++i & 1023) == 0) - cond_resched(); ret = fn(task, arg); + /* Avoid potential softlockup warning */ + cond_resched(); } css_task_iter_end(&it); if (ret) { -- 2.34.1

2 1

[PATCH OLK-5.10] memcg: always call cond_resched() after fn()
by Chen Ridong 29 May '25

29 May '25

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.15-rc1 commit 06717a7b6c86514dbd6ab322e8083ffaa4db5712 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBE42N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- I am seeing soft lockup on certain machine types when a cgroup OOMs. This is happening because killing the process in certain machine might be very slow, which causes the soft lockup and RCU stalls. This happens usually when the cgroup has MANY processes and memory.oom.group is set. Example I am seeing in real production: [462012.244552] Memory cgroup out of memory: Killed process 3370438 (crosvm) .... .... [462037.318059] Memory cgroup out of memory: Killed process 4171372 (adb) .... [462037.348314] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [stat_manager-ag:1618982] .... Quick look at why this is so slow, it seems to be related to serial flush for certain machine types. For all the crashes I saw, the target CPU was at console_flush_all(). In the case above, there are thousands of processes in the cgroup, and it is soft locking up before it reaches the 1024 limit in the code (which would call the cond_resched()). So, cond_resched() in 1024 blocks is not sufficient. Remove the counter-based conditional rescheduling logic and call cond_resched() unconditionally after each task iteration, after fn() is called. This avoids the lockup independently of how slow fn() is. Link: https://lkml.kernel.org/r/20250523-memcg_fix-v1-1-ad3eafb60477@debian.org Fixes: ade81479c7dd ("memcg: fix soft lockup in the OOM process") Signed-off-by: Breno Leitao <leitao(a)debian.org> Suggested-by: Rik van Riel <riel(a)surriel.com> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Michael van der Westhuizen <rmikey(a)meta.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Cc: Pavel Begunkov <asml.silence(a)gmail.com> Cc: Chen Ridong <chenridong(a)huawei.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/memcontrol.c [context is mispatched] Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- mm/memcontrol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index d9467b38e2f7..fc7f211bcdc7 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1202,7 +1202,6 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg, { struct mem_cgroup *iter; int ret = 0; - int i = 0; BUG_ON(memcg == root_mem_cgroup); @@ -1212,10 +1211,9 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg, css_task_iter_start(&iter->css, CSS_TASK_ITER_PROCS, &it); while (!ret && (task = css_task_iter_next(&it))) { - /* Avoid potential softlockup warning */ - if ((++i & 1023) == 0) - cond_resched(); ret = fn(task, arg); + /* Avoid potential softlockup warning */ + cond_resched(); } css_task_iter_end(&it); if (ret) { -- 2.34.1

2 1

[PATCH OLK-6.6] memcg: always call cond_resched() after fn()
by Chen Ridong 29 May '25

29 May '25

From: Breno Leitao <leitao(a)debian.org> mainline inclusion from mainline-v6.15-rc1 commit 06717a7b6c86514dbd6ab322e8083ffaa4db5712 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBE42N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- I am seeing soft lockup on certain machine types when a cgroup OOMs. This is happening because killing the process in certain machine might be very slow, which causes the soft lockup and RCU stalls. This happens usually when the cgroup has MANY processes and memory.oom.group is set. Example I am seeing in real production: [462012.244552] Memory cgroup out of memory: Killed process 3370438 (crosvm) .... .... [462037.318059] Memory cgroup out of memory: Killed process 4171372 (adb) .... [462037.348314] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [stat_manager-ag:1618982] .... Quick look at why this is so slow, it seems to be related to serial flush for certain machine types. For all the crashes I saw, the target CPU was at console_flush_all(). In the case above, there are thousands of processes in the cgroup, and it is soft locking up before it reaches the 1024 limit in the code (which would call the cond_resched()). So, cond_resched() in 1024 blocks is not sufficient. Remove the counter-based conditional rescheduling logic and call cond_resched() unconditionally after each task iteration, after fn() is called. This avoids the lockup independently of how slow fn() is. Link: https://lkml.kernel.org/r/20250523-memcg_fix-v1-1-ad3eafb60477@debian.org Fixes: ade81479c7dd ("memcg: fix soft lockup in the OOM process") Signed-off-by: Breno Leitao <leitao(a)debian.org> Suggested-by: Rik van Riel <riel(a)surriel.com> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Michael van der Westhuizen <rmikey(a)meta.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Cc: Pavel Begunkov <asml.silence(a)gmail.com> Cc: Chen Ridong <chenridong(a)huawei.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- mm/memcontrol.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 00b04c0ce172c..b3609b71cbe8f 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1322,7 +1322,6 @@ void mem_cgroup_scan_tasks(struct mem_cgroup *memcg, { struct mem_cgroup *iter; int ret = 0; - int i = 0; BUG_ON(mem_cgroup_is_root(memcg)); @@ -1332,10 +1331,9 @@ void mem_cgroup_scan_tasks(struct mem_cgroup *memcg, css_task_iter_start(&iter->css, CSS_TASK_ITER_PROCS, &it); while (!ret && (task = css_task_iter_next(&it))) { - /* Avoid potential softlockup warning */ - if ((++i & 1023) == 0) - cond_resched(); ret = fn(task, arg); + /* Avoid potential softlockup warning */ + cond_resched(); } css_task_iter_end(&it); if (ret) { -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] CVE-2022-49647
by Chen Ridong 29 May '25

29 May '25

CVE-2022-49647 Chen Ridong (1): cgroup: fix kabi for css_set Tejun Heo (1): cgroup: Use separate src/dst nodes when preloading css_sets for migration include/linux/cgroup-defs.h | 5 +++++ kernel/cgroup/cgroup.c | 25 +++++++++++++++++-------- 2 files changed, 22 insertions(+), 8 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-58100 5.10
by Chen Zhongjin 29 May '25

29 May '25

*** BLURB HERE *** Eduard Zingerman (2): bpf: check changes_pkt_data property for extension programs bpf: fix null dereference when computing changes_pkt_data of prog w/o subprogs include/linux/bpf.h | 1 + kernel/bpf/verifier.c | 19 +++++++++++++++---- 2 files changed, 16 insertions(+), 4 deletions(-) -- 2.25.1

2 3

[openeuler:OLK-6.6 2331/2331] drivers/crypto/ccp/hygon/psp-dev.c:35:6: sparse: sparse: symbol 'psp_in_nowait_mode' was not declared. Should it be static?
by kernel test robot 29 May '25

29 May '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: fb62fea0a81a08823f133facca690b2f666a49ef commit: 3907486bfebfabd1b4cfcfd94fdb04d617e68db8 [2331/2331] crypto: ccp: support psp generic ringbuffer config: x86_64-randconfig-121-20250529 (https://download.01.org/0day-ci/archive/20250529/202505292025.Uqstjrf4-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250529/202505292025.Uqstjrf4-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/202505292025.Uqstjrf4-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/crypto/ccp/hygon/psp-dev.c:35:6: sparse: sparse: symbol 'psp_in_nowait_mode' was not declared. Should it be static? drivers/crypto/ccp/hygon/psp-dev.c:47:10: sparse: sparse: symbol 'atomic64_exchange' was not declared. Should it be static? drivers/crypto/ccp/hygon/psp-dev.c:52:5: sparse: sparse: symbol 'psp_mutex_init' was not declared. Should it be static? vim +/psp_in_nowait_mode +35 drivers/crypto/ccp/hygon/psp-dev.c 34 > 35 bool psp_in_nowait_mode; 36 static struct psp_misc_dev *psp_misc; 37 #define HYGON_PSP_IOC_TYPE 'H' 38 enum HYGON_PSP_OPCODE { 39 HYGON_PSP_MUTEX_ENABLE = 1, 40 HYGON_PSP_MUTEX_DISABLE, 41 HYGON_VPSP_CTRL_OPT, 42 HYGON_PSP_OP_PIN_USER_PAGE, 43 HYGON_PSP_OP_UNPIN_USER_PAGE, 44 HYGON_PSP_OPCODE_MAX_NR, 45 }; 46 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 V1] sched: Support NUMA parallel scheduling for multiple processes
by Cheng Yu 29 May '25

29 May '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/ICBBNL -------------------------------- For architectures with multiple NUMA node levels and large distances between nodes, a better approach is to support processes running in parallel on each NUMA node. The usage is restricted to the following scenarios: 1. No CPU binding for user-space processes; 2. It is applicable to distributed applications, such as business architectures with one master and multiple slaves running in parallel; 3. The existing "qos dynamic affinity" and "qos smart grid" features must not be used simultaneously. Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- arch/arm64/Kconfig | 1 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/mm/numa.c | 74 ++++++++++++++++++++++++++ include/linux/perf_event.h | 2 + include/linux/sched.h | 3 ++ init/Kconfig | 22 ++++++++ kernel/cgroup/cpuset.c | 8 ++- kernel/events/core.c | 13 +++++ kernel/sched/debug.c | 37 +++++++++++++ kernel/sched/fair.c | 26 ++++++++- kernel/sched/features.h | 4 ++ 11 files changed, 187 insertions(+), 4 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 93ced97f8c6c..76f07a283d4e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -79,6 +79,7 @@ config ARM64 select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && (GCC_VERSION >= 50000 || CC_IS_CLANG) select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_SUPPORTS_SCHED_KEEP_ON_CORE + select ARCH_SUPPORTS_SCHED_PARAL select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT select ARCH_WANT_DEFAULT_BPF_JIT diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index fb9f92d11bde..4dd4994d6fbb 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -190,6 +190,7 @@ CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_STEAL=y CONFIG_SCHED_KEEP_ON_CORE=y +CONFIG_SCHED_PARAL=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c index 99a746e14f2b..6340513bab65 100644 --- a/arch/arm64/mm/numa.c +++ b/arch/arm64/mm/numa.c @@ -777,3 +777,77 @@ void __init arm64_numa_init(void) numa_init(dummy_numa_init); } + +#ifdef CONFIG_SCHED_PARAL +#include <linux/perf_event.h> + +static atomic_t paral_nid_last = ATOMIC_INIT(-1); + +int probe_pmu_numa_event(void) +{ + struct perf_event *event; + struct perf_event_attr attr = {}; + int type = perf_pmu_type_of_name("hisi_sccl3_hha0"); + + if (type == -1) + return -EINVAL; + + attr.type = type; + attr.config = 0x02; + attr.size = sizeof(struct perf_event_attr); + attr.pinned = 1; + attr.disabled = 1; + attr.sample_period = 0; + + event = perf_event_create_kernel_counter(&attr, smp_processor_id(), + NULL, NULL, NULL); + if (IS_ERR(event)) + return PTR_ERR(event); + + perf_event_release_kernel(event); + + return 0; +} + +static inline int update_sched_paral_nid(void) +{ + int onid, nnid; + + do { + onid = atomic_read(&paral_nid_last); + nnid = (onid >= INT_MAX) ? 0 : (onid + 1); + } while (atomic_cmpxchg(&paral_nid_last, onid, nnid) != onid); + + return nnid; +} + +void set_task_paral_node(struct task_struct *p) +{ + int nid; + int i = 0; + const cpumask_t *cpus_mask; + + if (is_global_init(current)) + return; + + if (p->flags & PF_KTHREAD || p->tgid != p->pid) + return; + + while (i < nr_node_ids) { + nid = update_sched_paral_nid() % nr_node_ids; + cpus_mask = cpumask_of_node(nid); + + if (cpumask_empty(cpus_mask) || + !cpumask_subset(cpus_mask, p->cpus_ptr)) { + i++; + continue; + } + + cpumask_copy(p->prefer_cpus, cpus_mask); + break; + } +} +#else +void set_task_paral_node(struct task_struct *p) {} +int probe_pmu_numa_event(void) { return -1; } +#endif diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 2544bfdd948b..7814ff2e45c7 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -1485,6 +1485,7 @@ extern void perf_event_task_tick(void); extern int perf_event_account_interrupt(struct perf_event *event); extern int perf_event_period(struct perf_event *event, u64 value); extern u64 perf_event_pause(struct perf_event *event, bool reset); +extern int perf_pmu_type_of_name(const char *name); #else /* !CONFIG_PERF_EVENTS: */ static inline void * perf_aux_output_begin(struct perf_output_handle *handle, @@ -1577,6 +1578,7 @@ static inline u64 perf_event_pause(struct perf_event *event, bool reset) { return 0; } +static inline int perf_pmu_type_of_name(const char *name) { return -1; } #endif #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL) diff --git a/include/linux/sched.h b/include/linux/sched.h index e3170b7f81fa..181230773350 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -2309,6 +2309,9 @@ int set_prefer_cpus_ptr(struct task_struct *p, int sched_prefer_cpus_fork(struct task_struct *p, struct cpumask *mask); void sched_prefer_cpus_free(struct task_struct *p); void dynamic_affinity_enable(void); +bool sched_paral_used(void); +void set_task_paral_node(struct task_struct *p); +int probe_pmu_numa_event(void); #endif #ifdef CONFIG_QOS_SCHED_SMART_GRID diff --git a/init/Kconfig b/init/Kconfig index 3a6a14e66acd..5f88cce193e8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1389,6 +1389,28 @@ config SCHED_KEEP_ON_CORE otherwise the task will not be migrated and the cpu0 will still be used. +# +# For architectures that want to enable the support for SCHED_PARAL +# +config ARCH_SUPPORTS_SCHED_PARAL + bool + +config SCHED_PARAL + bool "Parallelly schedule processes on different NUMA nodes" + depends on ARCH_SUPPORTS_SCHED_PARAL + depends on QOS_SCHED_DYNAMIC_AFFINITY + default n + help + By enabling this feature, processes can be scheduled in parallel + on various NUMA nodes to better utilize the cache in NUMA node. + The usage is restricted to the following scenarios: + 1. No CPU binding is performed for user-space processes; + 2. It is applicable to distributed applications, such as business + architectures with one master and multiple slaves running in + parallel; + 3. The existing "qos dynamic affinity" and "qos smart grid" + features must not be used simultaneously. + config CHECKPOINT_RESTORE bool "Checkpoint/restore support" select PROC_CHILDREN diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 7ecff06d2026..1f6ed08af9f5 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2423,7 +2423,8 @@ static void cpuset_attach(struct cgroup_taskset *tset) */ WARN_ON_ONCE(set_cpus_allowed_ptr(task, cpus_attach)); #ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY - set_prefer_cpus_ptr(task, prefer_cpus_attach); + if (!sched_paral_used() || !cpumask_empty(prefer_cpus_attach)) + set_prefer_cpus_ptr(task, prefer_cpus_attach); #endif cpuset_change_task_nodemask(task, &cpuset_attach_nodemask_to); @@ -3131,7 +3132,10 @@ static void cpuset_fork(struct task_struct *task) set_cpus_allowed_ptr(task, current->cpus_ptr); #ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY - set_prefer_cpus_ptr(task, current->prefer_cpus); + rcu_read_lock(); + if (!sched_paral_used() || !cpumask_empty(task_cs(current)->prefer_cpus)) + set_prefer_cpus_ptr(task, current->prefer_cpus); + rcu_read_unlock(); #endif task->mems_allowed = current->mems_allowed; } diff --git a/kernel/events/core.c b/kernel/events/core.c index b56b572f1bd0..e0c193083aa0 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -13167,6 +13167,19 @@ static int __init perf_event_sysfs_init(void) } device_initcall(perf_event_sysfs_init); +int perf_pmu_type_of_name(const char *name) +{ + unsigned int i; + struct pmu *pmu; + + idr_for_each_entry(&pmu_idr, pmu, i) { + if (!strcmp(pmu->name, name)) + return pmu->type; + } + + return -1; +} + #ifdef CONFIG_CGROUP_PERF static struct cgroup_subsys_state * perf_cgroup_css_alloc(struct cgroup_subsys_state *parent_css) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 4275398bc713..d6b53d54dcf5 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -96,6 +96,39 @@ static void sched_feat_disable(int i) { }; static void sched_feat_enable(int i) { }; #endif /* CONFIG_JUMP_LABEL */ +#ifdef CONFIG_SCHED_PARAL +static void sched_feat_disable_paral(char *cmp) +{ + struct task_struct *tsk, *t; + + if (strncmp(cmp, "PARAL", 5) == 0) { + read_lock(&tasklist_lock); + for_each_process(tsk) { + if (tsk->flags & PF_KTHREAD || is_global_init(tsk)) + continue; + + for_each_thread(tsk, t) + cpumask_clear(t->prefer_cpus); + } + read_unlock(&tasklist_lock); + } +} + +static bool sched_feat_enable_paral(char *cmp) +{ + if (strncmp(cmp, "PARAL", 5) != 0) + return true; + + if (probe_pmu_numa_event() != 0) + return false; + + return true; +} +#else +static void sched_feat_disable_paral(char *cmp) {}; +static bool sched_feat_enable_paral(char *cmp) { return true; }; +#endif /* CONFIG_SCHED_PARAL */ + static int sched_feat_set(char *cmp) { int i; @@ -112,8 +145,12 @@ static int sched_feat_set(char *cmp) if (neg) { sysctl_sched_features &= ~(1UL << i); + sched_feat_disable_paral(cmp); sched_feat_disable(i); } else { + if (!sched_feat_enable_paral(cmp)) + return -EPERM; + sysctl_sched_features |= (1UL << i); sched_feat_enable(i); } diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 437572c568ee..396c2b87c012 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8063,6 +8063,16 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) } #ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY +bool sched_paral_used(void) +{ +#ifdef CONFIG_SCHED_PARAL + if (sched_feat(PARAL)) + return true; +#endif + + return false; +} + static DEFINE_STATIC_KEY_FALSE(__dynamic_affinity_used); static __always_inline bool dynamic_affinity_used(void) @@ -8168,6 +8178,14 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, } rcu_read_unlock(); + /* In extreme cases, it may cause uneven system load. */ + if (sched_paral_used() && sysctl_sched_util_low_pct == 100 && nr_cpus_valid > 0) { + p->select_cpus = p->prefer_cpus; + if (sd_flag & SD_BALANCE_WAKE) + schedstat_inc(p->se.statistics.nr_wakeups_preferred_cpus); + return; + } + /* * Follow cases should select cpus_ptr, checking by condition of * tg_capacity > nr_cpus_valid: @@ -8225,7 +8243,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f #endif #ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY - if (dynamic_affinity_used() || smart_grid_used()) + if (dynamic_affinity_used() || smart_grid_used() || sched_paral_used()) set_task_select_cpus(p, &idlest_cpu, sd_flag); #endif @@ -9867,7 +9885,7 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env) #ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY p->select_cpus = p->cpus_ptr; - if (dynamic_affinity_used() || smart_grid_used()) + if (dynamic_affinity_used() || smart_grid_used() || sched_paral_used()) set_task_select_cpus(p, NULL, 0); if (!cpumask_test_cpu(env->dst_cpu, p->select_cpus)) { #else @@ -13549,6 +13567,10 @@ static void task_fork_fair(struct task_struct *p) } se->vruntime -= cfs_rq->min_vruntime; + + if (sched_paral_used()) + set_task_paral_node(p); + rq_unlock(rq, &rf); } diff --git a/kernel/sched/features.h b/kernel/sched/features.h index fb885b20ba34..1fd89af55681 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -74,6 +74,10 @@ SCHED_FEAT(STEAL, false) SCHED_FEAT(KEEP_ON_CORE, false) #endif +#ifdef CONFIG_SCHED_PARAL +SCHED_FEAT(PARAL, false) +#endif + /* * Issue a WARN when we do multiple update_rq_clock() calls * in a single rq->lock section. Default disabled because the -- 2.25.1

2 1

[openeuler:OLK-6.6 2331/2331] drivers/crypto/ccp/hygon/vpsp.c:64:1: sparse: sparse: symbol 'vpsp_cmd_ctx_table' was not declared. Should it be static?
by kernel test robot 29 May '25

29 May '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: e2c7f21ccac8f595f261a7971f6d6092d442c888 commit: 294caf049d134e08f0e70277ddb6a29698e9d96b [2331/2331] crypto: ccp: Use a workqueue to clean up the vpsp ringbuffer config: x86_64-randconfig-121-20250529 (https://download.01.org/0day-ci/archive/20250529/202505291807.LPmsH7Fj-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250529/202505291807.LPmsH7Fj-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/202505291807.LPmsH7Fj-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/crypto/ccp/hygon/vpsp.c:64:1: sparse: sparse: symbol 'vpsp_cmd_ctx_table' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/vpsp.c:65:1: sparse: sparse: symbol 'table_rwlock' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/vpsp.c:695:1: sparse: sparse: symbol 'vpsp_dev_rwlock' was not declared. Should it be static? drivers/crypto/ccp/hygon/vpsp.c:724:10: sparse: sparse: symbol 'allow_default_vid' was not declared. Should it be static? drivers/crypto/ccp/hygon/vpsp.c:725:6: sparse: sparse: symbol 'vpsp_set_default_vid_permission' was not declared. Should it be static? vim +/vpsp_cmd_ctx_table +64 drivers/crypto/ccp/hygon/vpsp.c 33 34 /* 35 * The file mainly implements the base execution logic of virtual PSP in kernel mode, 36 * which mainly includes: 37 * (1) Preprocess the guest data in the host kernel 38 * (2) The command that has been converted will interact with the channel of the 39 * psp through the driver and try to obtain the execution result 40 * (3) The executed command data is recovered, and then returned to the VM 41 * 42 * The primary implementation logic of virtual PSP in kernel mode 43 * call trace: 44 * guest command(vmmcall, KVM_HC_PSP_COPY_FORWARD_OP) 45 * | 46 * kvm_pv_psp_copy_op----> | -> kvm_pv_psp_cmd_pre_op 47 * | 48 * | -> vpsp_try_do_cmd/vpsp_try_get_result 49 * | |<=> psp device driver 50 * | 51 * | 52 * |-> kvm_pv_psp_cmd_post_op 53 * 54 * guest command(vmmcall, KVM_HC_PSP_FORWARD_OP) 55 * | 56 * kvm_pv_psp_forward_op-> |-> vpsp_try_do_cmd/vpsp_try_get_result 57 * |<=> psp device driver 58 */ 59 60 /** 61 * used to locate the command context, 62 * when the guest enters the host via vmmcall 63 */ > 64 DEFINE_HASHTABLE(vpsp_cmd_ctx_table, 11); > 65 DEFINE_RWLOCK(table_rwlock); 66 bool vpsp_in_ringbuffer_mode; 67 static struct vpsp_cmd_ctx *vpsp_cmd_ctx_array[CSV_COMMAND_PRIORITY_NUM] 68 [CSV_RING_BUFFER_SIZE / CSV_RING_BUFFER_ESIZE]; 69 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 v2 0/2] some fix about ifs
by Pu Lehui 29 May '25

29 May '25

Pu Lehui (1): interference: Fix compilation issue Xu Kuohai (1): interference: Fix IFS cannot show in cgroup v1 sub-cgroup drivers/base/arch_topology.c | 1 + include/linux/cgroup.h | 4 ++++ 2 files changed, 5 insertions(+) -- 2.34.1

2 3