[PATCH] mutex: make mutex_lock_nested an inline function

Peter Zijlstra peterz at infradead.org
Wed Oct 14 04:07:17 PDT 2015


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

Also, it will give a runtime warn if you ever do hit 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.

> I would be very surprised to see a system that pushes over 8 locks,
> while there's nothing actually preventing it system design
> considerations mean that even four cascaded supplies are pretty
> unlikely so we should be fine.  Every time you add a new level of
> regulation you're both increasing the load on regulators up the chain
> (which means they need to be bigger and more expensive) and except in
> the case of a DCDC supplying an LDO (which only works to one level)
> you're going to be decreasing the efficiency of the system.  If we get
> to that point we can worry about what to do.

OK I suppose.



More information about the linux-arm-kernel mailing list