Re: [PATCH 02/10] sched_ext: Fix ops.running/stopping() pairing for proxy-exec donors

On Sat, Jul 11, 2026 at 11:37:17AM +0200, Andrea Righi wrote:
> On Fri, Jul 10, 2026 at 02:33:55PM -0700, John Stultz wrote:
> > On Fri, Jul 10, 2026 at 1:39 AM Andrea Righi <[email protected]> wrote:
> > >
> > > With proxy-exec, pick_next_task() can return a task with blocked_on set
> > > (a proxy donor). put_prev_set_next_task() then calls set_next_task_scx()
> > > on this "ghost" task even though the task only provides scheduling
> > > context and never actually runs.
> > >
> > > Calling ops.running() for such a donor produces a spurious running
> > > event. Simply suppressing ops.running() is not sufficient because the
> > > following put_prev_task_scx() would still invoke ops.stopping(),
> > > resulting in an unpaired stopping event.
> > >
> > > Introduce SCX_TASK_IS_RUNNING to track whether a task entered a real
> > > running transition. Set and clear the flag independently of
> > > ops.running() and ops.stopping(), as the callbacks are independently
> > > optional. Invoke ops.running() only for non-blocked tasks and invoke
> > > ops.stopping() only after a real running transition. This keeps the
> > > callbacks paired for proxy donors while preserving stopping
> > > notifications for schedulers which only implement ops.stopping().
> > 
> > It took me a while to understand this.
> > 
> > It seems you're wanting to distinguish normal task selection and
> > execution (without proxy) from just task selection for proxy-donation
> > (where it doesn't run).
> > 
> > I think what makes it confusing is that TASK_IS_RUNNING is not set for
> > the case when the task is running (rq->curr) as a lock-owning proxy
> > for a waiting donor.
> > 
> > Would it maybe make it easier to follow if the flag was
> > TASK_BLOCKED_DONOR? And the logic was flipped a bit?
> > 
> > That might more clearly cover the case you intend here without extra
> > edge cases that you'll have to explain (well, you're running but
> > you're not the donor and running... ).
> 
> I agree that SCX_TASK_IS_RUNNING is confusing, because it doesn't describe
> really well the rq->curr/physical execution.
> 
> What the flag records is whether a task entered the sched_ext running/stopping
> state. With proxy-exec, the selected scheduling context (rq->donor) and the
> physical execution context (rq->curr) can differ, which creates two relevant
> cases:
> 
>  1. a blocked EXT donor goes through set_next_task_scx() even though its mutex
>     owner executes instead. We must suppress ops.running() for the donor and
>     remember that it did not enter the running state, so that a later
>     ops.stopping() is also suppressed,
> 
>  2. an EXT mutex owner can execute as rq->curr for a non-EXT donor. The owner is
>     not a blocked donor, but it did not go through set_next_task_scx(), so it
>     must not receive ops.stopping() if it is subsequently dequeued.
> 
> So, I don't think changing the flag to SCX_TASK_BLOCKED_DONOR captures the
> required state. SCX_TASK_IS_RUNNING handles both cases by recording whether the
> task entered the sched_ext ops.running/stopping() state, independently of
> whether either callback is implemented.
> 
> How about renaming it to SCX_TASK_IN_RUNNING_TRANSITION and explicitly
> documenting that this is the sched_ext callback state, not physical rq->curr
> execution? Something like:
> 
>   /* entered the SCX ops.running/stopping() state, not necessarily rq->curr */
>   SCX_TASK_IN_RUNNING_TRANSITION = 1 << 6,
> 
> Any other ideas for a more clear name?

Or perhaps SCX_TASK_RUN_TRACKED (I think I prefer this one). I did other changes
to the series, so I'll post a new version with this rename as well. Then we can
continue the discussion in the new thread.

Thanks,
-Andrea