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: <ZseXqP6q7qyFeiCO@casper.infradead.org>
Date: Thu, 22 Aug 2024 20:55:20 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Mark Brown <broonie@...nel.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:48:56PM +0100, Mark Brown wrote:
> 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.

When it's an uncontended spinlock, there's really no overhead.  I wish I'd
been firmer on that point earlier and prohibited the external lock hack.

The point is that the lock protects the tree.  If we are ever going to
be able to defragment slabs (and I believe this is an ability that Linux
must gain), we must be able to go from the object (the maple node) to
a lock that will let us reallocate the node.  If there's some external
lock that protects the tree, we can't possibly do that.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ