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: <1244534315.5024.34.camel@penberg-laptop>
Date:	Tue, 09 Jun 2009 10:58:35 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mel Gorman <mel@....ul.ie>, Rik van Riel <riel@...hat.com>,
	Larry Finger <Larry.Finger@...inger.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>, npiggin@...e.de
Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb

Hi David,

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> Larry reported this stack trace:
> 
> kernel: git: page allocation failure. order:1, mode:0x4020
> kernel: Pid: 3707, comm: git Not tainted 2.6.30-rc1-wl #115
> kernel: Call Trace:
> kernel:  [<ffffffff80292f84>] __alloc_pages_internal+0x43d/0x45d
> kernel:  [<ffffffff802b2383>] alloc_pages_current+0xbe/0xc6
> kernel:  [<ffffffff802b66a4>] new_slab+0xcf/0x28b
> 
> That's in the order fallback for new slab allocations; so this cache must 
> have oo_order(s->min) of 1.

Yes, agreed which is why I said it's unlikely that the allocated size is
800 bytes or so.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> To diagnose whether its object size dictates a >0 slab order, you could 
> enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which 
> /sys/kernel/slab/cache/order_fallback increased.  Once you have identified 
> the cache, you can get this information via 
> /sys/kernel/slab/cache/{objsize,order,size}.  I think this is what 
> Christoph was getting at.
> 
> You could even boot with `slub_nomerge' to determine whether cache merging 
> was the issue where the cache under consideration was unnecessarily merged 
> with one that requires larger higher order minimums.

Sure. Applying my diagnostic patch will probably shed some light on the
subject too.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> I don't quite understand how its necessary to print the partial lists for 
> each node, they should be exhausted if we're allocating a new slab if the 
> node doesn't matter (and can't in Larry's case, he only has one).

It doesn't hurt either, does it? Yes, we expect the partial lists to be
exhausted but it's better to print that out just in case we have a bug
some day somewhere and that condition is not true. This is very
infrequent slow patch code here anyway.

			Pekka

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ