linux-kernel - Re: [PATCH 1/2] regmap: teach regmap to use raw spinlocks if requested in the config

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 02 Sep 2021 10:35:01 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Lee Jones <lee.jones@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, Marc Zyngier <maz@...nel.org>,
        Hou Zhiqiang <Zhiqiang.Hou@....com>,
        Biwen Li <biwen.li@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] regmap: teach regmap to use raw spinlocks if
 requested in the config

On Wed, Sep 01 2021 at 17:05, Mark Brown wrote:
> On Mon, Aug 30, 2021 at 04:16:04PM +0200, Thomas Gleixner wrote:
>> On Mon, Aug 30 2021 at 13:19, Mark Brown wrote:
>
>> > That probably does make sense, I think we're just using regular
>> > spinlocks for spinlocks mainly because they're the default rather
>> > than because anyone put huge amounts of thought into it.  IIRC
>> > the first users were using spinlocks for their locking when they
>> > were converted.
>
>> So if the actual spinlock protected operations are not doing any other
>> business than accessing preallocated cache memory and a few MMIO
>> operations then converting them to raw spinlocks should have no real
>> impact on RT.
>
> I think Vladimir's point that something might try to use one of the APIs
> that can do multiple register writes atomically to generate a very long
> register write sequence is valid here.  It's far from the common case
> but it'd be hard to audit, it's going to be a lot easier to handle going
> to raw spinlocks in the cases where it's specifically needed than to
> keep on top of ensuring that none of the users are causing issues or
> start causing issues in the future.  This does make me feel it's a bit
> safer to leave the default the way it is since if you get it wrong then
> lockdep will tend to notice very quickly while it's less likely that
> we'd get tooling spotting issues the other way around.

Fair enough.

>> One way to do that is obviously starting with the patch from Vladimir
>> and then convert them one by one, so the assumption that they are not
>> doing anything nasty (in the RT sense) can be validated.
>
> Vladimir's patch is in Linus' tree now so users that can safely do so
> can start using raw spinlocks.

ok