Re: [PATCH v2 1/2] sched: proxy-exec: Close race causing workqueue work being delayed

[John Stultz]

On Sun, May 3, 2026 at 10:37 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 5/4/2026 12:12 AM, K Prateek Nayak wrote:
> > So when looking at all of this, I realized we probably don't need
> > PROXY_WAKING anymore if we have the "is_blocked" state in task_struct.
> > The owner can simply clear the blocked_on and move along and the
> > waiter's "is_blocked" state will handle the sched bits.
> >
> > (p->is_blocked && !p->blocked_on) can then be interpreted as
> > PROXY_WAKING and that task should explore return migration in
> > find_proxy_task().
> >
> > Would something like below be more amenable from a backport standpoint
> > instead of marking the config broken?
> >
> @@ -6535,8 +6548,10 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
>          * blocked on a mutex, and we want to keep it on the runqueue
>          * to be selectable for proxy-execution.
>          */
> -       if (!should_block)
> +       if (!should_block) {
> +               sched_set_task_is_blocked(p);
>                 return false;
> +       }
>

So digging a bit more into this, it seems is_blocked in your patch is
semantically different from what Peter was proposing.

Peter seemed to be suggesting is_blocked would be more generic then
just for proxy-exec, getting set in try_to_block_task() regardless if
we actually blocked the task or not, and then clearing it in
ttwu_do_wakeup() when we go RUNNABLE.  Pretty much independent of
blocked_on.

Where as your patch is still having is_blocked very much tied with
blocked_on (since with yours we only set is_blocked if we avoid
blocking the task in try_to_block_task(), and clear it only from
find_proxy_task()).
In a way I can map your approach utilizing is_blocked as conceptually
sort of separating the latch bit from my last approach, (if we also
re-worked PROXY_WAKING to be the value 1 (!blocked_on + latch) instead
of -1).  So your approach seems workable (I've got it about half way
integrated with my full series - hitting a little bit of trouble with
the sleeping owner enquing at the moment), but I'm not sure this is
what Peter is looking for.

thanks
-john