linux-kernel - Re: [Bug #13319] Page allocation failures with b43 and p54usb

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:	Tue, 9 Jun 2009 01:14:59 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
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

On Tue, 9 Jun 2009, Pekka Enberg 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.
> 

I wasn't sure whether you were proposing the patch as an addition to slub 
or just to help with this issue.  I agree it would help in a hopefully 
ratelimited manner for general slab allocation failures and would have 
avoided some of the confusion for this issue from lack of diagnostics.

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

It will lead to false postiives since you can get a free to a full slab 
which moves it back to an allowed node's partial list before count_free() 
is printed.
--
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/