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

[Peter Zijlstra]

On Tue, May 05, 2026 at 08:58:38PM -0700, John Stultz wrote:
> On Mon, May 4, 2026 at 9:37 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> > On 5/5/2026 9:02 AM, John Stultz wrote:
> > > but I'm not sure this is what Peter is looking for.
> >
> > Well this was just an option in case we don't want to backport super
> > invasive changes.
> >
> > That said, we can easily do the following on top to fit what Peter
> > originally suggested (although it'll probably require a bit effort to
> > integrate with the sleeping owner bits):
> >
> ...
> >
> > Attached is full diff as proxy.diff on top of tip:sched/core for
> > convenience. I'll let Peter comment further if he likes this
> > approach or not :-)
> 
> Thanks again for sharing this!
> 
> So, I believe I've now got my full stack working ontop of your
> proxy.diff file here (though as you pointed out there may be some
> dragons left in the sleeping owner patch, but I *think* its ok).
> 
> That said, I'm still not confident Peter won't still want his approach
> (since it seems he's scheming to use is_blocked for se.sched_delayed
> as well. That and I'm a bit shy after sinking so much time into the
> last approach he didn't like :), so I've *also* worked up my full
> series with Peter's approach (his change slots in after we get the
> ttwu return migration in place).

Sorry ;-)

> So I'm totally fine if Peter agrees to take your version as a near
> term fix for 7.1-rc.  But if he'd rather not, I'll try to move forward
> with his approach combined with the next chunk of patches.
> 
> 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.
> 
> 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.

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.

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.