Messages in this thread | | | From | Nick Piggin <> | Subject | Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate reclaim context (__GFP_NOFS), fix SLOB) | Date | Mon, 16 Mar 2009 20:49:57 +1100 |
| |
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@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? > > 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.
| |