Re: [PATCH] mutex: make mutex_lock_nested an inline function

[Mark Brown]

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.

Attachment: signature.asc
Description: PGP signature