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

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

Message-ID: <alpine.DEB.2.00.0906300032310.11018@chino.kir.corp.google.com>
Date:	Tue, 30 Jun 2009 00:47:25 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	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>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb

On Tue, 30 Jun 2009, Pekka Enberg wrote:

> > I'd disagree with disabling slub debugging by default for caches where
> > oo_order(s->min) increases as the result of using it.  This particular
> > page allocation failure is happening for, presumably, kmalloc-4096, and
> > the system has 4K pages.  Disabling debugging for that cache (and any of
> > its aliases) implicitly will lead to errors going undiagnosed as a result.
> 
> Well, I obviously don't agree here because kmalloc-4096 debugging
> causes problems in the real world.

I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in 
the real world.

The option has a clear and well-defined purpose and that is to enable 
debugging on all slab caches.  If you modify its definition, users will 
generally ignore the warning about debugging being disabled when "the 
minimum possible order at which slab may be allocated is higher than 
without."  And unless they check the kernel log for such a warning to boot 
with `slab_debug=,kmalloc-4096', we lose testing coverage because we 
cannot enable redzoning or tracing after boot.

> Furthermore, SLUB never supported
> debugging for objects that big historically because of page allocator
> passthrough. And with Mel Gorman's page allocator optimizations, we
> might be going back to that.
> 

Even when page allocation is fast enough, it would still be helpful to 
configure slub to not do passthrough purely for the lightweight debugging 
opportunities.

> So we should fix SLUB debugging as outlined by Mel Gorman and
> Christoph Lameter. I simply haven't had the time to do it. Patches are
> welcome!
> 

You're referring to `slub_debug=A'?  I think CONFIG_SLUB_DEBUG_ON should 
continue to enable debugging on all slab caches and in instances where it 
causes page allocation failures such in Larry's case because 
oo_order(s->min) with debugging on is greater than oo_order(s->min) with 
debugging off, you can emit a friendly warning in your recently added 
slab_out_of_memory() about using `slab_debug=-,<cache>'.

We have a disagreement about which is the default behavior, but I would 
opt on the side of adding exemptions to a debug configuration option as 
opposed to requiring additional command line parameters to be fully 
enabled.