linux-kernel - Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map

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]

Message-ID: <ZseWKBCkxTrJfEot@finisterre.sirena.org.uk>
Date: Thu, 22 Aug 2024 20:48:56 +0100
From: Mark Brown <broonie@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
	maple-tree@...ts.infradead.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] maple_tree: Allow external locks to be configured
 with their map

On Thu, Aug 22, 2024 at 08:21:40PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 22, 2024 at 08:13:35PM +0100, Mark Brown wrote:

> > Currently the maple tree code allows external locks to be configured by
> > passing the lock itself. This is generally helpful and convenient but is

> No, it's a really bad idea.  Stop doing it.  Use the internal lock.
> It's a temporary hack we put in and I'm really regretting allowing it.

I mean, we do use the internal lock here since otherwise lockdep moans
but it's pure overhead which just complicates the code.  It's only ever
taken within another lock, meaning it winds up protecting nothing for
these maple trees.  We can't go the other way round and use the maple
tree lock as the regmap lock since apart from anything else it's a spin
lock and we need to use a mutex most of the time to support busses that
sleep during I/O.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)