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

[Peter Zijlstra]

On Tue, Apr 28, 2026 at 06:45:39PM +0530, K Prateek Nayak wrote:

> > Something like so perhaps?
> > 
> > ---
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 368c7b4d7cb5..0bd5da8360f3 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -846,7 +846,11 @@ struct task_struct {
> >  	struct alloc_tag		*alloc_tag;
> >  #endif
> >  
> > -	int				on_cpu;
> > +	u8				on_cpu;
> > +	u8				on_rq;
> > +	u8				is_blocked;
> > +	u8				__pad;
> > +
> >  	struct __call_single_node	wake_entry;
> >  	unsigned int			wakee_flips;
> >  	unsigned long			wakee_flip_decay_ts;
> > @@ -861,7 +865,6 @@ struct task_struct {
> >  	 */
> >  	int				recent_used_cpu;
> >  	int				wake_cpu;
> > -	int				on_rq;
> >  
> >  	int				prio;
> >  	int				static_prio;
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index da20fb6ea25a..06817ae0cbd9 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -615,6 +615,13 @@ EXPORT_SYMBOL(__trace_set_current_state);
> >   *   [ The astute reader will observe that it is possible for two tasks on one
> >   *     CPU to have ->on_cpu = 1 at the same time. ]
> >   *
> > +*  p->is_blocked <- { 0, 1 }:
> > +*
> > +*    is set by block_task() and cleared by ttwu_do_activate() and indicates
> > +*    this task is blocked, as opposed to runnable. Used to distinguish between
> > +*    preempted and blocked tasks for proxy exec, which keeps everything on the
> > +*    runqueue.
> > + *
> >   * task_cpu(p): is changed by set_task_cpu(), the rules are:
> >   *
> >   *  - Don't call set_task_cpu() on a blocked task:
> > @@ -2225,6 +2232,7 @@ void deactivate_task(struct rq *rq, struct task_struct *p, int flags)
> >  
> >  static void block_task(struct rq *rq, struct task_struct *p, int flags)
> >  {
> > +	p->is_blocked = 1;
> 
> We never reach here with PROXY_EXEC. Instead we bail out in the caller
> try_to_block_task() ...
> 
> >  	if (dequeue_task(rq, p, DEQUEUE_SLEEP | flags))
> >  		__block_task(rq, p);
> >  }
> > @@ -3722,6 +3730,7 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags,
> >  		atomic_dec(&task_rq(p)->nr_iowait);
> >  	}
> >  
> > +	p->is_blocked = 0;
> >  	activate_task(rq, p, en_flags);
> >  	wakeup_preempt(rq, p, wake_flags);
> >  
> > @@ -7107,7 +7116,7 @@ static void __sched notrace __schedule(int sched_mode)
> >  		struct task_struct *prev_donor = rq->donor;
> >  
> >  		rq_set_donor(rq, next);
> > -		if (unlikely(next->blocked_on)) {
> > +		if (unlikely(next->is_blocked && next->blocked_on)) {
> 
> ... so ->is_blocked here is always false for proxy tasks retained on
> the runqueue.

Right. Also, egads, we really should fix that block/ttwu part, this is a
mess.

Anyway, idea is simple even if execution turns into a bit of a mess now,
set when task really is blocked and clear on wakeup.

> I was trying something like below but I'm somewhere missing a
> clear_task_blocked_on() for PROXY_WAKING before going back into
> mutex_lock_common():
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8ec3b6d7d718b..6ea74aecc5fbd 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -586,6 +586,7 @@ struct sched_entity {
>  	unsigned char			sched_delayed;
>  	unsigned char			rel_deadline;
>  	unsigned char			custom_slice;
> +	unsigned char			sched_proxy;
>  					/* hole */

Should not live in sched_entity I suppose.