Re: [PATCH v30 3/7] sched/core: Don't proxy-exec unmatched cookie lock owners

[John Stultz]

On Thu, Jul 9, 2026 at 8:14 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 7/8/2026 10:30 AM, John Stultz wrote:
> >> https://lore.kernel.org/lkml/9ceb2af0-33c6-40ca-b855-5167a9c5ae0f@xxxxxxx/
> >>
> >
> > Oh! Very interesting! My apologies for somehow having overlooked this mail!
> >
> >
> >> I can streamline that more on top of current tip to do it all in
> >> pick_next_task() but the bigger question is, is it worth all the
> >> complexity?
> >>
> >> John, Peter, what do you think?
> >>
> >> [..snip..]
> >>
> >>> @@ -7004,6 +7004,14 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> >>>               owner->blocked_donor = p;
> >>>       }
> >>>       WARN_ON_ONCE(owner && !owner->on_rq);
> >>> +
> >>> +     if (owner && !sched_cpu_cookie_match(rq, owner)) {
> >>> +             if (curr_in_chain)
> >>> +                     return proxy_resched_idle(rq);
> >>> +             p = donor; /* Deactivate the donor, not the runnable owner */
> >>> +             clear_task_blocked_on(p, NULL);
> >>> +             goto deactivate;
> >>> +     }
> >>
> >> Otherwise, this is acceptable if we don't want to touch core-sched
> >> bits juts yet.
> >
> > Vasily's patch I think is a reasonable short-term solution just to
> > avoid breaking core-scheduling with proxy, but it's not a great
> > solution as it just disables proxy in the problematic cases.
>
> Ack! We can add this in and work on the CORE_SCHED bits before we drop
> the EXPERT dependency perhaps?
>

Of course! I'm not in any rush to drop EXPERT.


> I doubt if anyone would notice if PROXY is missing with CORE_SCHED but
> if and when we plan to retire RT_MUTEXES in favor of PROXY_EXEC, we
> should have it in for correctness.
>

Agreed.

> > So I'm very interested in your proposal, as I was thinking I'd have to
> > pick folks' brains at LPC to figure out a better approach. But it
> > might be worth taking Vasily's patch while yours gets polished and
> > tested?
> > I'll try pulling your change in to test with my full tree.
>
> I'll send a clean series out by early next week after some more testing
> on top of your WIP branch.

Ok, I've been tinkering with your patch a bit already today. Though, I
need to figure out some better testing tools for core-sched so I can
properly validate the correctness.

thanks!
-john