Messages in this thread |  | | Date | Mon, 08 Dec 2025 10:10:07 +0000 | | Subject | Re: [RFC][PATCH] sched/ext: Avoid null ptr traversal when ->put_prev_task() is called with NULL next | | From | Kuba Piecuch <> |
| |
Hello John,
On Sat Dec 6, 2025 at 2:22 AM UTC, John Stultz wrote: > I can't say I understand why this doesn't trip usually without > proxy-exec. And in newer kernels there are way fewer > put_prev_task(), and I can't easily reproduce the issue now > even with proxy-exec.
That's probably because put_prev_task_scx() with next == NULL is always preceded by a dequeue, clearing SCX_TASK_QUEUED from p->scx.flags, so we don't reach the problematic sched_class_above() check because it only happens when the flag is set.
> But we still have one put_prev_task() call left in core.c that > seems like it could trip this, so I wanted to send this out for > consideration.
I'm assuming you're referring to the one in sched_change_begin(). It looks like it's impossible for an outside observer holding a CPU's rq lock to observe a task that is running on that CPU and isn't queued, i.e. 'running' implies 'queued' (I'm new to the scheduler so I may be wrong here). That would explain why dequeue_task() is always called before put_prev_task(). Does proxy execution break that assumption?
Best, Kuba
|  |