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 for Android: free password hash cracker in your pocket

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

Message-Id: <1237128960.3213.133.camel@calx>
Date:	Sun, 15 Mar 2009 09:56:00 -0500
From:	Matt Mackall <mpm@...enic.com>
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>,
	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	tglx@...utronix.de
Subject: Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate
	reclaim context (__GFP_NOFS), fix SLOB)

On Sun, 2009-03-15 at 20:06 +1100, Nick Piggin 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?

Yeah. I don't think any of the allocators are designed with recursion in
mind. That the others aren't (visibly) failing here is blind luck.

Nick, not really sure what your patch is accomplishing. It narrows the
lock window, but it doesn't eliminate it. But I think we can take the
page allocator case out from under the lock entirely, no?

diff -r 8e0f1cee0a71 mm/slob.c
--- a/mm/slob.c	Sat Jan 24 15:41:13 2009 -0600
+++ b/mm/slob.c	Sun Mar 15 09:50:42 2009 -0500
@@ -387,8 +387,6 @@
 	sp = (struct slob_page *)virt_to_page(block);
 	units = SLOB_UNITS(size);
 
-	spin_lock_irqsave(&slob_lock, flags);
-
 	if (sp->units + units == SLOB_UNITS(PAGE_SIZE)) {
 		/* Go directly to page allocator. Do not pass slob allocator */
 		if (slob_page_free(sp))
@@ -396,9 +394,11 @@
 		clear_slob_page(sp);
 		free_slob_page(sp);
 		free_page((unsigned long)b);
-		goto out;
+		return;
 	}
 
+	spin_lock_irqsave(&slob_lock, flags);
+
 	if (!slob_page_free(sp)) {
 		/* This slob page is about to become partially free. Easy! */
 		sp->units = units;

-- 
http://selenic.com : development and support for Mercurial and Linux


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