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

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Sep 21, 2026 at 06:27:12PM +0800, Quchaosheng wrote:
> CONFIG_SCHED_PROXY_EXEC could not be enabled together with
> CONFIG_PREEMPT_RT. The Kconfig entry carried a "depends on !PREEMPT_RT"
> with the comment "Avoid some build failures w/ PREEMPT_RT until it can be
> fixed", and the failures are real: building kernel/sched/core.c with both
> options set gives:
> 
>   kernel/sched/core.c:6927: error: passing argument 2 of 'clear_task_blocked_on' from incompatible pointer type
>   kernel/sched/core.c:6939: error: 'struct mutex' has no member named 'wait_lock'
>   kernel/sched/core.c:6943: error: implicit declaration of function '__get_task_blocked_on'
>   kernel/sched/core.c:6956: error: implicit declaration of function '__mutex_owner'
> 
> The proxy execution machinery tracks a task's blocked-on mutex through
> task_struct::blocked_on and walks that chain in find_proxy_task(). It was
> written against the native struct mutex, which embeds wait_lock directly
> and keeps the owner in atomic_long_t owner.
> 
> On PREEMPT_RT, struct mutex is instead a wrapper around struct rt_mutex,
> so both live in the embedded rt_mutex_base: wait_lock is
> rtmutex.wait_lock and the owner is reachable via rt_mutex_owner(). On top
> of that, the RT variants of the blocked_on accessors were stubbed out with
> a struct rt_mutex * parameter, so find_proxy_task() could not even compile.
> 
> The set of errors has two independent causes, addressed separately:
> 
> 1. Header type mismatch. The PREEMPT_RT branch of the blocked_on helpers
>    was declared with "struct rt_mutex *" while every caller passes a
>    "struct mutex *". That parameter type came from __ww_mutex_die() and
>    __ww_mutex_wound() in ww_mutex.h, which are shared with the WW_RT
>    instantiation where the MUTEX macro expands to struct rt_mutex. Those
>    two call sites are now compiled out for WW_RT, making the helpers
>    consistently take a "struct mutex *". This is not a behavioural change
>    for WW_RT: the blocked_on relation is only maintained for native
>    mutexes, and an rt_mutex based lock relies on the rtmutex priority
>    inheritance chain instead.
> 
> 2. Data structure access. Add mutex_wait_lock(), which returns the
>    wait_lock of either mutex implementation, and provide a
>    PREEMPT_RT __mutex_owner() that reads rt_mutex_base::owner, so that
>    find_proxy_task() works on both.
> 
> With that, the Kconfig restriction can be dropped.
> 
> Note that this makes the combination build and boot; it does not make
> proxy execution actually do anything useful on PREEMPT_RT. A task's
> blocked_on is only ever set by the native mutex slow path, which is
> compiled out when PREEMPT_RT is set, so task_is_blocked() is always false
> and find_proxy_task() is never reached. An rt_mutex already provides
> priority inheritance, so there is no blocked_on chain to follow either.
> Making proxy execution functional on PREEMPT_RT would require the RT
> mutex implementation to maintain blocked_on as well; that is not part of
> this change.
> 
> Verified with a full x86_64 build plus a QEMU boot of the resulting
> SMP PREEMPT_RT kernel, both with and without CONFIG_SCHED_PROXY_EXEC and
> with PROVE_LOCKING, DEBUG_ATOMIC_SLEEP and DEBUG_PREEMPT enabled. The
> kernel boots clean and an 8-thread SCHED_FIFO pthread mutex stress loop
> runs without any BUG or WARNING.
> 

I would like to wait with this until such time that we're are indeed
ready to drop rt_mutex entirely. Having the build option but it being
effectively 'broken' just doesn't make much sense to me.