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: <200903152104.25683.nickpiggin@yahoo.com.au>
Date:	Sun, 15 Mar 2009 21:04:24 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	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 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?


> this lockup does not trigger under any of the other allocators.

SLAB I suspect could trigger it (AFAIKS it frees pages back to the
allocator with locks held), but it has much more queueing and buffering
than SLOB, so it would probably be much harder to trigger it.

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