linux-kernel - Re: [PATCH] mutex: make mutex_lock

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: <20151014123624.GV14956@sirena.org.uk>
Date:	Wed, 14 Oct 2015 13:36:24 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Liam Girdwood <lgirdwood@...il.com>, akpm@...ux-foundation.org,
	Sascha Hauer <kernel@...gutronix.de>
Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function

On Wed, Oct 14, 2015 at 01:07:17PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 11:27:06AM +0100, Mark Brown wrote:
> > On Wed, Oct 14, 2015 at 10:20:50AM +0200, Peter Zijlstra wrote:

> > > Uuh, I just looked at next and saw this regulator_lock_supply()
> > > function. How is that limited? subclass must be <8 otherwise bad things
> > > happen.

> > Can we please get some more discoverable documentation of the arbitrary
> > limits in the lockdep code? 

> include/linux/lockdep.h:#define MAX_LOCKDEP_SUBCLASSES          8UL

Sure, but I don't really expect to have to trawl the implementation of
an API to find out about this sort of thing (I hadn't even been aware
that the subclasses were required to be small positive integers, never
mind needing to check what the limit was).  I think the main place I'd
have expected to see it was in lockdep-design.txt or somewhere near
that.

> > I seem to keep seeing code that bumps into
> > surprising limits like this and I'm not sure how I'm supposed to know
> > about them except through finding out after the fact or trawling the
> > code every time someone touches locking.

> Not knowing what other limits you've hit, I'm not entirely sure how to
> help out there.

The other big one that came up recently was that lockdep apparently
works out what a class is by looking at the point of allocation which
causes a lot of problems for regmap since it makes all regmap locks look
like a single class.  That's fixed now by explicitly allocating a class
per regmap with some macro magic but it was a bit of a surprise.  The
documentation doesn't make this obvious.

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