Messages in this thread Patch in this message |  | | From | Andrea Righi <> | | Subject | [PATCH 02/10] sched/core: Skip put_prev_task/set_next_task re-entry for sched_ext donors | | Date | Wed, 6 May 2026 19:45:42 +0200 |
| |
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
|  |