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.
signature.asc
Description: PGP signature
