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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html