Re: [PATCH] sched/proxy: allow SCHED_PROXY_EXEC with PREEMPT_RT

[Quchaosheng]

On 2026-09-21 12:09:21 [+0200], Sebastian Andrzej Siewior wrote:
> Why exactly is this a good thing to do?

You are right to ask, and the commit message buries the answer instead of
leading with it.

Under PREEMPT_RT this changes nothing at runtime. p->blocked_on is only
ever set from the native mutex slow path in kernel/locking/mutex.c, and
those call sites sit inside the existing "#ifndef CONFIG_PREEMPT_RT"
block, so blocked_on stays NULL and task_is_blocked() is always false.
find_proxy_task() therefore takes the "if (!mutex)" path and returns
before it reaches mutex_wait_lock(), which means both accessors added by
this patch are dead code when PREEMPT_RT is set.

What the patch does is make a combination that the Kconfig itself already
documents as broken ("Avoid some build failures w/ PREEMPT_RT until it can
be fixed") compile again, and drop the RT stub in include/linux/sched.h
whose parameter type did not match any caller. That is the whole of it.

If that is not worth carrying, I would rather withdraw the patch than
argue for it. Enabling a config that silently does nothing is a fair
objection, and teaching the RT mutex to maintain blocked_on is the real
work here.

The v2 I sent shortly after your mail crossed with it; it only fixes a Cc
address, a comment indentation and the wording of that note, so this
thread is still the right place to decide.