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]

Message-ID: <1275602282.2533.72.camel@edumazet-laptop>
Date:	Thu, 03 Jun 2010 23:58:02 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 16083] New: swapper: Page allocation failure

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

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