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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello John,

On 5/1/2026 2:10 AM, John Stultz wrote:
>> Any wait for non-special states that is not a loop is fundamentally
>> broken, since many of the lock wake-up paths are explicitly racy in that
>> they can cause spurious wakeups (which is the safe side of the race,
>> since insufficient wakeups is bad etc.).
>>
>> OTOH special states, are special, esp. because they cannot handle
>> spurious wakeups.
>>
>> Eg, consider something like:
>>
>>         set_current_state(TASK_FROZEN)
>>         <PREEMPT>
>>           current->__state = TASK_RUNNING
>>         </PREEMPT/
>>         schedule();
>>
>> is all sorts of broken. Now, obiously special states must never have
>> blocked_on set, so this can be fudged about. But still, touching __state
>> from schedule seems wrong.
> 
> Hey Peter,
>   Thanks again for the background here and the alternative proposal
> that K Prateek and I have iterated on.
> 
> I did want to clarify one case here just for my understanding. The
> approach in this first proposal was sort of leaning on the similar
> pattern in the signal_pending_state() case in try_to_block_task().  Is
> that just a hard exception to the rule here?

signal_pending_state() looks at the task_state only at a SM_NONE /
SM_RTLOCK_WAIT preemption point before making a call and only sets to
TASK_RUNNING if the state is (TASK_INTERRUPTIBLE | TASK_WAKEKILL) and
there is a signal pending. All the wakeups for that are routed through

Everything outside that state and coming from a SM_PREEMPT path will
leave the task state untouched in __schedule() until it hits the
natural SM_NONE / SM_RTLOCK_WAIT preemption point.

Only looking at ->blocked_on, and not the prev_state to set prev to
TASK_RUNNING can be dangerous. That said, it would be stupid for a
task to sets a special state and decide to grab a mutex which
overrides the state.

With the latch design, we are more or less aligned with something
similar to signal_pending_state() that looks at the tasks state from
a safe preemption point.

-- 
Thanks and Regards,
Prateek