linux-kernel - Re: GFP_ATOMIC page allocation failures.

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: <4864179E.8070700@redhat.com>
Date:	Thu, 26 Jun 2008 18:26:38 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Dave Jones <davej@...hat.com>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Chris Snook <csnook@...hat.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: GFP_ATOMIC page allocation failures.

Dave Jones wrote:
> This thread seemed to die out with no resolution..
> 
> On Thu, Apr 03, 2008 at 12:59:22PM +0400, Evgeniy Polyakov wrote:
>  > On Wed, Apr 02, 2008 at 10:32:54PM -0700, Andrew Morton (akpm@...ux-foundation.org) wrote:
>  > > > > It also tells us when we mucked up the net driver - I doubt if we (or at
>  > > > > least, I) would have discovered that e1000 does a 32k allocation for a
>  > > > > 5k(?) frame if this warning wasn't coming out.
>  > > > 
>  > > > Is that right? If it is allocating for 9K MTU, then the slab allocator
>  > > > (slub in this case) will bump that up to the 16K kmalloc slab. If it is
>  > > > a 5K frame, then it would get the 8K kmalloc slab I think.
>  > > > 
>  > > > Oh, but SLUB's default MIN_OBJECTS is 4, so 4*8 is 32 indeed. So slub
>  > > > is probably deciding to round the kmalloc-8192 allocations up to order-3.
>  > > > I think. How did you know it was a 5k frame? :)
>  > > 
>  > > urgh, it was a while ago, and I don't know if e1000e retains the behaviour.
>  > > 
>  > > iirc the issue was with some errant versions of the hardware needing
>  > > exorbitant alignment and additional padding at the end because of
>  > > occasional DMA overruns.  Something like that.
>  > 
>  > e1000 hardware does require power-of-two alignment, network stack adds
>  > additional structure at the end, so with e1000 it ends up with two
>  > rounds to the higher power of two.
>  > 5k ends up with 16k allocations, 9k - to 32k.
>  > 
>  > This problem is known for years already and number of fixes was
>  > proposed, but the really good one is to rewrite e1000 allocation path to
>  > use fragments, which I believe was done in the new e1000 driver.
> 
> So this morning, we got a fresh report from this in 2.6.25.6's e1000 driver
> https://bugzilla.redhat.com/show_bug.cgi?id=453010
> Pages and pages of spew, which make users freak out.
> This stuff might be 'nice to know', but if it isn't getting fixed,
> I can see why some distros have been shipping the 'silence GFP_ATOMIC failures'
> patches for some time.
> 
> 	Dave
> 
>  > And as a side note: shuting allocation failures is a very bad step,
>  > since it hides allocation problems for drivers. if people do care about
>  > it add __GFP_SMALL_WARN flag which will just print that allocation
>  > failed, its order and function where it happend.

Maybe we should make __GFP_SMALL_WARN the default behavior, and allow subsystems 
to silence or print the full warning if they see fit.  That solves most of the 
spew, while still preserving the most important information for debugging, and 
still gives subsystem maintainers the power to do as they see fit.

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