Re: [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock_t.

[Guenter Roeck <linux@roeck-us.net>]

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