lkml.org 
[lkml]   [2026]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH 02/10] sched/core: Skip put_prev_task/set_next_task re-entry for sched_ext donors
Date
In __schedule(), the proxy-exec donor-stabilization block calls
put_prev_task() and set_next_task() when rq->donor == prev_donor and
prev != next.

For sched_ext tasks, re-entering set_next_task_scx() for a donor that
has already been seen by BPF ops.running via the normal pick path causes
issues. It fires SCX_CALL_OP_TASK(sch, running, rq, donor) a second
time, and sch->ops dispatch can land on a vtable slot in a state that
yields a NULL function pointer or corrupts the stack.

Fix this by skipping the put_prev_task/set_next_task re-entry when the
donor is in the ext_sched_class, since sched_ext tracks curr/donor
itself.

Signed-off-by: Andrea Righi <arighi@nvidia.com>
---
kernel/sched/core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 75541e5bb66d1..1c161dd9d7440 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7147,9 +7147,14 @@ static void __sched notrace __schedule(int sched_mode)
* anything, since B == B. However, A might have
* missed a RT/DL balance opportunity due to being
* on_cpu.
+ *
+ * sched_ext tracks curr/donor itself; re-entering set_next_task_scx
+ * here dispatches through a stale/NULL BPF ops vtable.
*/
- donor->sched_class->put_prev_task(rq, donor, donor);
- donor->sched_class->set_next_task(rq, donor, true);
+ if (donor->sched_class != &ext_sched_class) {
+ donor->sched_class->put_prev_task(rq, donor, donor);
+ donor->sched_class->set_next_task(rq, donor, true);
+ }
}
} else {
rq_set_donor(rq, next);
--
2.54.0

\
 
 \ /
  Last update: 2026-05-06 19:49    [W:0.142 / U:16.257 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog