linux-kernel - Re: [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <48b9d642-9739-4333-b4b9-319df8a85e2d@redhat.com>
Date: Tue, 26 Nov 2024 11:59:09 -0500
From: Waiman Long <llong@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Waiman Long <llong@...hat.com>
Cc: Guenter Roeck <linux@...ck-us.net>, 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>,
 Andreas Larsson <andreas@...sler.com>
Subject: Re: [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock_t.

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.

Cheers,
Longman