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

[K Prateek Nayak]

Hello John,

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?

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.

> 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.

-- 
Thanks and Regards,
Prateek