On 11/27/24 07:39, Andreas Larsson wrote:
On 2024-11-26 17:59, Waiman Long wrote:
On 11/26/24 6:20 AM, Sebastian Andrzej Siewior wrote:
On 2024-11-25 15:54:48 [-0500], Waiman Long wrote:
FWIW, the description of commit 560af5dc839 is misleading. It says
"Enable
PROVE_RAW_LOCK_NESTING _by default_" (emphasis mine). That is not what
the
commit does. It force-enables PROVE_RAW_LOCK_NESTING if PROVE_LOCKING is
enabled. It is all or nothing.
I think we can relax it by
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5d9eca035d47..bfdbd3fa2d29 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1399,7 +1399,7 @@ config PROVE_LOCKING
config PROVE_RAW_LOCK_NESTING
bool
depends on PROVE_LOCKING
- default y
+ default y if ARCH_SUPPORTS_RT
help
Enable the raw_spinlock vs. spinlock nesting checks which ensure
that the lock nesting rules for PREEMPT_RT enabled kernels are
Sebastian, what do you think?
All the changes Guenter proposed make sense and were limited to sparc.
So we could apply that. Limiting the option to the RT architectures
would silence the warnings. If there is no interest in getting RT on
sparc there is probably no interest in getting the lock ordering
straight.
I remember PeterZ did not like the option in the beginning but there was
no way around it especially since printk triggered it on boot.
I'm fine with both solutions (fixing sparc or limiting
PROVE_RAW_LOCK_NESTING). I leave the final judgment to the locking
people.
Right now, ARCH_SUPPORTS_RT is defined for most of the major arches
where most of the testings are being done. So even if we limit this to
just those arches, we will not lose much testing anyway. This does have
the advantage of not forcing other legacy arches from doing extra works
with no real gain from their point of view.
Even though this is for sparc64, there is work being done looking into
enabling RT for sparc32. If the amount of fixes needed to keep
PROVE_RAW_LOCK_NESTING enabled is quite small at the moment I'd rather
see it enabled for sparc rather than risking it becoming worse in the
future.
I don't know what the situation is for other architectures that does not
support RT.
For my part I still don't understand why PROVE_RAW_LOCK_NESTING is no longer
a configurable option, or in other words why it is mandated even for architectures
not supporting RT. To me this means that I'll either have to disable PROVE_LOCKING
for sparc or live with endless warning backtraces. The latter obscures real
problems, so it is a no-go.
So, if people want to keep mandating PROVE_RAW_LOCK_NESTING together with
PROVE_LOCKING for all architectures, I'll disable PROVE_LOCKING for sparc
in my testing. NP, just let me know. I'll then do the same for other
architectures not supporting RT if I hit the same problem there.
Guenter
