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] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bl5fggrf.ffs@tglx>
Date:   Mon, 30 Aug 2021 16:16:04 +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 Mon, Aug 30 2021 at 13:19, Mark Brown wrote:
> On Fri, Aug 27, 2021 at 01:01:35AM +0200, Thomas Gleixner wrote:
>> On Wed, Aug 25 2021 at 23:50, Vladimir Oltean wrote:
>
>> > It seems reasonable for regmap to have an option use a raw spinlock too,
>> > so add that in the config such that drivers can request it.
>
>> What's reasonable about that?
>
>> What exactly prevents the regmap locking to use a raw spinlock
>> unconditionally?
>
> We definitely can't use a raw spinlock unconditionally since we
> support register maps on devices connected via buses which can't
> be accessed atomically so we need the option of doing mutexes.

The mutex part is fine. For slow busses this is obviously required.

>> Even for the case where the regmap is not dealing with irq chips it does
>> not make any sense to protect low level operations on shared register
>> with a regular spinlock. I might be missing something though...
>
> 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.

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.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ