[PATCH] sched/proxy: allow SCHED_PROXY_EXEC with PREEMPT_RT

[PATCH] sched/proxy: allow SCHED_PROXY_EXEC with PREEMPT_RT

[Quchaosheng]

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. An rt_mutex
already provides priority inheritance, so there is no blocked_on chain to
follow and proxy execution stays inactive. Replacing rt_mutexes in the RT
mutex implementation is tracked as future work in the proxy execution
series.

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.

Signed-off-by: Quchaosheng <quchaosheng000406@163.com>
---
 include/linux/sched.h     | 11 -----------
 init/Kconfig              |  6 ++++--
 kernel/locking/mutex.h    | 36 ++++++++++++++++++++++++++++++++++--
 kernel/locking/ww_mutex.h | 24 ++++++++++++++++--------
 kernel/sched/core.c       |  2 +-
 5 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 705970d07614..334935d0ab55 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2216,8 +2216,6 @@ extern int __cond_resched_rwlock_write(rwlock_t *lock) __must_hold(lock);
 	__cond_resched_rwlock_write(lock);					\
 })
 
-#ifndef CONFIG_PREEMPT_RT
-
 static inline struct mutex *__get_task_blocked_on(struct task_struct *p)
 {
 	lockdep_assert_held_once(&p->blocked_lock);
@@ -2258,15 +2256,6 @@ static inline void clear_task_blocked_on(struct task_struct *p, struct mutex *m)
 	guard(raw_spinlock_irqsave)(&p->blocked_lock);
 	__clear_task_blocked_on(p, m);
 }
-#else
-static inline void __clear_task_blocked_on(struct task_struct *p, struct rt_mutex *m)
-{
-}
-
-static inline void clear_task_blocked_on(struct task_struct *p, struct rt_mutex *m)
-{
-}
-#endif /* !CONFIG_PREEMPT_RT */
 
 static __always_inline bool need_resched(void)
 {
diff --git a/init/Kconfig b/init/Kconfig
index 8583d9f06c52..c4fca7951658 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -936,8 +936,6 @@ config UCLAMP_BUCKETS_COUNT
 
 config SCHED_PROXY_EXEC
 	bool "Proxy Execution"
-	# Avoid some build failures w/ PREEMPT_RT until it can be fixed
-	depends on !PREEMPT_RT
 	# Need to investigate how to inform sched_ext of split contexts
 	depends on !SCHED_CLASS_EXT
 	# Not particularly useful until we get to multi-rq proxying
@@ -946,6 +944,10 @@ config SCHED_PROXY_EXEC
 	  This option enables proxy execution, a mechanism for mutex-owning
 	  tasks to inherit the scheduling context of higher priority waiters.
 
+	  On PREEMPT_RT the mutex implementation already provides priority
+	  inheritance via rt_mutex, so proxy execution has no blocked_on
+	  chains to follow and the feature is effectively inactive there.
+
 endmenu
 
 #
diff --git a/kernel/locking/mutex.h b/kernel/locking/mutex.h
index 3e263e98e5fc..4e8b26840669 100644
--- a/kernel/locking/mutex.h
+++ b/kernel/locking/mutex.h
@@ -6,8 +6,25 @@
  *
  *  Copyright (C) 2004, 2005, 2006 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
  */
-#ifndef CONFIG_PREEMPT_RT
 #include <linux/mutex.h>
+
+/*
+ * Where a mutex keeps its wait_lock differs between the two mutex
+ * implementations: native mutexes embed it directly, while PREEMPT_RT mutexes
+ * wrap an rt_mutex and keep it in rt_mutex_base. Provide a common accessor for
+ * the scheduler's proxy-execution code, which takes this lock to pin down a
+ * mutex owner.
+ */
+static inline raw_spinlock_t *mutex_wait_lock(struct mutex *lock)
+{
+#ifdef CONFIG_PREEMPT_RT
+	return &lock->rtmutex.wait_lock;
+#else
+	return &lock->wait_lock;
+#endif
+}
+
+#ifndef CONFIG_PREEMPT_RT
 /*
  * This is the control structure for tasks blocked on mutex, which resides
  * on the blocked task's kernel stack:
@@ -76,4 +93,19 @@ extern void debug_mutex_init(struct mutex *lock);
 # define debug_mutex_unlock(lock)			do { } while (0)
 # define debug_mutex_init(lock)				do { } while (0)
 #endif /* !CONFIG_DEBUG_MUTEXES */
-#endif /* CONFIG_PREEMPT_RT */
+
+#else /* CONFIG_PREEMPT_RT */
+
+/*
+ * On PREEMPT_RT a mutex is an rt_mutex, which keeps track of its owner in
+ * rt_mutex_base::owner. Expose it through the same helper the native mutex
+ * path uses so that the proxy-execution scheduler code builds for both.
+ */
+static inline struct task_struct *__mutex_owner(struct mutex *lock)
+{
+	if (!lock)
+		return NULL;
+	return rt_mutex_owner(&lock->rtmutex);
+}
+
+#endif /* !CONFIG_PREEMPT_RT */
diff --git a/kernel/locking/ww_mutex.h b/kernel/locking/ww_mutex.h
index d62b49b53ec3..5cb65daf1c88 100644
--- a/kernel/locking/ww_mutex.h
+++ b/kernel/locking/ww_mutex.h
@@ -323,8 +323,14 @@ __ww_mutex_die(struct MUTEX *lock, struct MUTEX_WAITER *waiter,
 		 * When waking up the task to die, be sure to set the
 		 * blocked_on to PROXY_WAKING. Otherwise we can see
 		 * circular blocked_on relationships that can't resolve.
+		 *
+		 * The blocked_on relation is only maintained for native
+		 * mutexes; on PREEMPT_RT an rt_mutex based lock relies on
+		 * priority inheritance instead.
 		 */
+#ifndef WW_RT
 		clear_task_blocked_on(waiter->task, lock);
+#endif
 		wake_q_add(wake_q, waiter->task);
 	}
 
@@ -375,15 +381,17 @@ static bool __ww_mutex_wound(struct MUTEX *lock,
 		 */
 		if (owner != current) {
 			/*
-			 * When waking up the task to wound, be sure to set the
-			 * blocked_on to PROXY_WAKING. Otherwise we can see
-			 * circular blocked_on relationships that can't resolve.
-			 *
-			 * NOTE: We pass NULL here instead of lock, because we
-			 * are waking the mutex owner, who may be currently
-			 * blocked on a different mutex.
-			 */
+		 * When waking up the task to wound, be sure to set the
+		 * blocked_on to PROXY_WAKING. Otherwise we can see
+		 * circular blocked_on relationships that can't resolve.
+		 *
+		 * NOTE: We pass NULL here instead of lock, because we
+		 * are waking the mutex owner, who may be currently
+		 * blocked on a different mutex.
+		 */
+#ifndef WW_RT
 			clear_task_blocked_on(owner, NULL);
+#endif
 			wake_q_add(wake_q, owner);
 		}
 		return true;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b998ef6b87af..dcad037cbc08 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6936,7 +6936,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 		 * By taking mutex->wait_lock we hold off concurrent mutex_unlock()
 		 * and ensure @owner sticks around.
 		 */
-		guard(raw_spinlock)(&mutex->wait_lock);
+		guard(raw_spinlock)(mutex_wait_lock(mutex));
 		guard(raw_spinlock)(&p->blocked_lock);
 
 		/* Check again that p is blocked with blocked_lock held */
-- 
2.43.0

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

[Sebastian Andrzej Siewior]

On 2026-09-21 16:15:25 [+0800], Quchaosheng wrote:
> Note that this makes the combination build and boot; it does not make
> proxy execution actually do anything useful on PREEMPT_RT. An rt_mutex
> already provides priority inheritance, so there is no blocked_on chain to
> follow and proxy execution stays inactive. Replacing rt_mutexes in the RT
> mutex implementation is tracked as future work in the proxy execution
> series.

Why exactly is this a good thing to do?

> Signed-off-by: Quchaosheng <quchaosheng000406@163.com>

Sebastian

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.

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

[Sebastian Andrzej Siewior]

On 2026-09-21 18:51:44 [+0800], Quchaosheng wrote:
> On 2026-09-21 12:09:21 [+0200], Sebastian Andrzej Siewior wrote:
> > Why exactly is this a good thing to do?
> 
> 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.

Is there a build failure as of today or not?
The whole proxy exec thingy depends on !PREEMPT_RT, so there should be
no build failures.

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

I still fail to understand why we want it. It does nothing. The option
itself is document and once enabled CONFIG_SCHED_PROXY_EXEC does
something an !PREEMPT_RT and leads to a different behaviour if disabled.
But with your patch and PREEMPT_RT enabled there would be nothing that
CONFIG_SCHED_PROXY_EXEC does, would there be?

Sebastian

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

[Quchaosheng]

Sebastian, Peter,

Both of you asked the same thing, so one answer for the thread: you are
right, there is no build failure today. The option cannot be turned on
next to PREEMPT_RT, and that dependency is exactly why nobody has hit the
errors I quoted. My patch is what would introduce the combination, not
what fixes it. Answering "the Kconfig says it is broken" was circular.

Peter put the objection better than I did: the feature is effectively
broken under PREEMPT_RT, and carrying a build option in that state buys
nothing. I withdraw the patch.

The boot and stress testing I described was real, but it was testing a
combination that should not exist, which makes it worthless as an
argument. If proxy execution becomes meaningful on PREEMPT_RT it will be
after the RT mutex maintains blocked_on, and that change will have to
justify itself from that work.

Quchaosheng