[PATCH] sched/proxy: Correct the SCHED_PROXY_EXEC dependency comment

[Quchaosheng]

The comment on the !PREEMPT_RT dependency reads

	# Avoid some build failures w/ PREEMPT_RT until it can be fixed

That describes what happens once the dependency is removed, not the
reason it is there, and "fixed" is never defined, so nothing says when
the dependency can be dropped.

The build failures are real, but they are not the whole reason. Under
PREEMPT_RT a mutex is an rt_mutex, and its PI path takes pi_lock under
wait_lock and rq->lock under pi_lock. find_proxy_task() takes
mutex->wait_lock under rq->lock, so

	wait_lock -> pi_lock -> rq->lock -> wait_lock

closes into a cycle. It stays dormant only because nothing sets
blocked_on when PREEMPT_RT is set, and it is gone once a mutex is no
longer an rt_mutex, which is also the condition that lets the dependency
be dropped.

No functional change.

Link: https://lore.kernel.org/all/20260921102712.3245860-1-quchaosheng000406@xxxxxxx/
Signed-off-by: Quchaosheng <quchaosheng000406@xxxxxxx>
---
 init/Kconfig | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/init/Kconfig b/init/Kconfig
index 8583d9f..b45d8b2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -936,7 +936,11 @@ config UCLAMP_BUCKETS_COUNT
 
 config SCHED_PROXY_EXEC
 	bool "Proxy Execution"
-	# Avoid some build failures w/ PREEMPT_RT until it can be fixed
+	# Fixing the build failures is not enough: under PREEMPT_RT a mutex
+	# is an rt_mutex whose PI path takes pi_lock under wait_lock and
+	# rq->lock under pi_lock, while find_proxy_task() takes
+	# mutex->wait_lock under rq->lock. The two orders close a cycle that
+	# only goes away once a mutex is no longer an rt_mutex.
 	depends on !PREEMPT_RT
 	# Need to investigate how to inform sched_ext of split contexts
 	depends on !SCHED_CLASS_EXT
-- 
2.43.0