On Thu, Dec 19, 2013 at 05:01:16PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 19, 2013 at 10:59:17AM -0500, Dave Jones wrote:
> > On Thu, Dec 19, 2013 at 04:51:21PM +0100, Peter Zijlstra wrote:
> > > On Thu, Dec 19, 2013 at 10:39:57AM -0500, Sasha Levin wrote:
> > > > That discusses lockdep classes, which is actually fine in my case. I
> > ran out of
> > > > MAX_LOCKDEP_ENTRIES, which isn't mentioned anywhere in Documentation/
> > .
> > >
> > > Yeah, it suffers from the same problem though. Lockdep has static
> > > resource allocation and never frees them.
> > >
> > > The lock classes are the smallest pool and usually run out first, but
> > > the same could happen for the entries, after all, the more classes we
> > > have the more class connections can happen.
> > >
> > > Anyway, barring a leak and silly class mistakes like mentioned in the
> > > document there's nothing we can do except raise the number.
> >
> > I tried this. When you bump it to 32k, it fares better but then you
> > start seeing "BUG: MAX_LOCKDEP_CHAINS too low!" instead.
> > I've not tried bumping that yet, as I've stopped seeing these lately
> > due to hitting more serious bugs first.
>
> What are you doing to trigger all this? I don't see these. Are you
> loading/unloading modules a lot?
syscall fuzzing.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
