[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4eb7bb8e-c2aa-4ce5-9f15-3086fccf4e46@roeck-us.net>
Date: Wed, 27 Nov 2024 08:02:50 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Andreas Larsson <andreas@...sler.com>, Waiman Long <llong@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
Boqun Feng <boqun.feng@...il.com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock_t.
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
Powered by blists - more mailing lists