linux-kernel - Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate reclaim context (__GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903151614320.29264@localhost.localdomain>
Date:	Sun, 15 Mar 2009 16:16:34 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Ingo Molnar <mingo@...e.hu>, linux-tip-commits@...r.kernel.org,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	hpa@...or.com, mingo@...hat.com
Subject: Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate
 reclaim context (__GFP_NOFS), fix SLOB)

On Sun, 15 Mar 2009, Nick Piggin wrote:
> On Sunday 15 March 2009 20:47:04 Ingo Molnar wrote:
> > * Nick Piggin <nickpiggin@...oo.com.au> wrote:
> > > On Sunday 15 March 2009 17:48:18 Ingo Molnar wrote:
> > > > > Cc: Nick Piggin <npiggin@...e.de>
> > > > > Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> > > > > LKML-Reference: <20090128135457.350751756@...llo.nl>
> > > > > Signed-off-by: Ingo Molnar <mingo@...e.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.

Thanks,

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