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

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

Hello Peter, John,

On 5/6/2026 3:23 PM, Peter Zijlstra wrote:
>> That said, trying to keep this full jenga tower of patches ontop of
>> both sides of your dualing banjos here is non-trivial, and I also do
>> need to get a solution for devices using the full stack on 6.18 and
>> 6.12 android trees very soon, which I'd like to keep closely aligned
>> with upstream.

Sorry about that (T_T)

>>
>> So having a clear direction to go forward would be helpful. :)
>>
>> Peter: Do you have guidance here?
> 
> So yeah, I think you were feeling me right, I wanted to very much be
> able to use that is_blocked for sched_delayed too -- its always bothered
> me a little something to have to use se.sched_delayed in the core code.

We still mark the delayed task as is_blocked except we can't move the
clearing of is_blocked into ttwu_do_wakeup() just yet ...

> 
> That said, I think Prateek agrees that once we get return migration into
> ttwu(), this all becomes simpler. And I think his insight that we can
> use is_blocked && !blocked_on to replace PROXY_WAKING is still valid on
> top of all that.

... and yes, with the ttwu_runnable() bits, we can cleanly do that in
ttwu_do_wakeup() when setting TASK_RUNNING.

It might also give us a neat spot for waking up the tasks attached
to the sleeping owner but I've to still wrap my head around the
locking there.

> 
> Given this is all still very much an 'under construction' area, I don't
> think we need to rush fixes now. We can just slap 'BROKEN' on things and
> continue merging things for the next cycle.

Ack! We can focus on v29 and hopefully sort out everything by the
time next window rolls around and then we can tackle the dragons in
sleeping owner parts ;-)

-- 
Thanks and Regards,
Prateek