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]
Date:	Thu, 26 Jun 2008 17:06:24 -0400
From:	Dave Jones <davej@...hat.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	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.

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.



-- 
http://www.codemonkey.org.uk
--
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