Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate reclaim context (__GFP_NOFS), fix SLOB)
From: Nick Piggin
Date: Mon Mar 16 2009 - 05:57:21 EST
On Monday 16 March 2009 02:16:34 Thomas Gleixner wrote:
> 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.
Oh good, thanks for that.
--
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/