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

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Apr 27, 2026 at 06:38:40PM +0000, John Stultz wrote:

>  kernel/sched/core.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index da20fb6ea25ae..5f684caefd8b2 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7097,6 +7097,17 @@ static void __sched notrace __schedule(int sched_mode)
>  		try_to_block_task(rq, prev, &prev_state,
>  				  !task_is_blocked(prev));
>  		switch_count = &prev->nvcsw;
> +	} else if (preempt && prev->blocked_on) {
> +		/*
> +		 * If we are SM_PREEMPT, we may have interrupted
> +		 * after blocked_on was set, before schedule()
> +		 * was run, preventing workques from running. So

workqueues

> +		 * clear blocked_on and mark task RUNNING so it
> +		 * can be reselected to run and complete its
> +		 * logic
> +		 */
> +		WRITE_ONCE(prev->__state, TASK_RUNNING);
> +		clear_task_blocked_on(prev, NULL);
>  	}
>  
>  pick_again:

*groan*, this feels wrong. Preemption should never touch state. Let me
try and wake up and make sense of this.