sched/core: Don't proxy-exec unmatched cookie lock owners

Core scheduling chooses a core-wide cookie before __schedule()
installs the next task. With proxy-exec enabled, that task becomes the
donor/scheduling context, and find_proxy_task() may then replace the
execution context with the runnable mutex owner. If its cookie differs
from the selected core cookie, running it would bypass core scheduling's
cookie selection.

When the final mutex owner found by find_proxy_task() does not match the
selected core cookie, stop proxying the donor. If the current execution
context is already in the blocked chain, fall back to idle like the
existing proxy-exec retry paths do. Otherwise deactivate the donor and
let __schedule() pick again. The mutex owner can be picked later under
its own cookie.

Fixes: 7de9d4f946 ("sched: Start blocked_on chain processing in find_proxy_task()")
[jstultz: Added tweak to ensure we deactivate donor, not runnable owner]
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/lkml/10282ce9-f4ae-498f-9b57-f4e1e61fffbc@amd.com/
Link: https://patch.msgid.link/20260807035232.1881495-5-jstultz@google.com
This commit is contained in:
Vasily Gorbik 2026-08-07 03:52:10 +00:00 committed by Peter Zijlstra
parent 9be817f991
commit 09351db90a

View File

@ -7046,6 +7046,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;
}
return owner;
deactivate: