netdev - Re: [Bugme-new] [Bug 16083] New: swapper: Page allocation failure

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:	Thu, 3 Jun 2010 15:11:22 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 16083] New: swapper: Page allocation failure

On Thu, 03 Jun 2010 23:58:02 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le jeudi 03 juin 2010 __ 14:39 -0700, Andrew Morton a __crit :
> 
> > Well.  The presence of this warning does serve to remind us how sucky
> > e1000[e] is :(
> > 
> > I'm not particularly fussed either way - I'm just wondering if you guys
> > think this thing meets the noise-to-benefit test...
> > 
> 
> Well, in this particular case, I think its a genuine bug in the ipv6
> code, not on the e1000[e] driver :)
> 
> It allocates "a priori" dev->mtu sized skb that are filled by maybe one
> hundred bytes by caller.
> 
> With MTU=9000, this means order-2 allocations. In an ideal world, it
> would be fine, but in practice, we know only fools can trust high order
> allocations.
> 
> Since code is prepared to chain skbs, just make sure we cap allocations
> to smaller units (up to 0xe80 bytes on a 64bit kernel)
> 
> So in this particular case, the bugzilla report can point to a real
> problem in our stack.
> 
> Failed allocations had been silent, we probably would never have
> noticed.
> 
> Hmm...
> 

heh, in that case I guess we should leave it there.

But I do tend to ignore such reports, or fob them off with some
boilerplate.  It was pure luck that the one I chose as an example
happened to be interesting.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html