Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotatereclaim context (__GFP_NOFS), fix SLOB)

[Thomas Gleixner]

On Sun, 15 Mar 2009, Nick Piggin wrote:
> On Sunday 15 March 2009 20:47:04 Ingo Molnar wrote:
> > * Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
> > > On Sunday 15 March 2009 17:48:18 Ingo Molnar wrote:
> > > > > Cc: Nick Piggin <npiggin@xxxxxxx>
> > > > > Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> > > > > LKML-Reference: <20090128135457.350751756@xxxxxxxxx>
> > > > > Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> > > >
> > > > and with this fixed, and with SLOB now being tested in -tip, the
> > > > new lockdep assert attached below (followed by a real lockup)
> > > > pops up.
> > > >
> > > > Seems like a genuine SLOB bug, probably present upstream as
> > > > well.
> > >
> > > Hmmf. debugobjects calls back into the slab allocator from the
> > > page allocator. The following patch would improve SLOB, but I
> > > think it would be a good idea to avoid a dependency in that
> > > direction. Can debugobjects defer this freeing?
> >
> > dunno - that's a question for Thomas.
> 
> Well I think it could, and it should (just add them to a list and
> kick off a workqueue or something). It is not a good idea for
> fringe debug functionality like this to introduce such a connection
> between core code like this. Unless there is a *really* good reason.
> 
> Apart from the locking issue, I wonder if the recursion is bounded?

Yes. debugobject free does not call back into debugobjects, but you
are right it should defer the free. I have rcu based deferred free in
-rt for the very same reason. I'll whip up a solution for mainline as
well.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/