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

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Sunday 15 March 2009 20:47:04 Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > On Sunday 15 March 2009 17:48:18 Ingo Molnar wrote:
> > > > Cc: Nick Piggin <npiggin@suse.de>
> > > > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > > LKML-Reference: <20090128135457.350751756@chello.nl>
> > > > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > >
> > > 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?


> this lockup does not trigger under any of the other allocators.

SLAB I suspect could trigger it (AFAIKS it frees pages back to the
allocator with locks held), but it has much more queueing and buffering
than SLOB, so it would probably be much harder to trigger it.