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]

Date:	Mon, 16 Mar 2009 20:49:57 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Thomas Gleixner <tglx@...utronix.de>
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 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@...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.

Oh good, thanks for that.

--
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/