| 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
| ||
|
Date: Mon, 24 Oct 2011 09:21:52 +0200 From: Philipp Herz - Profihost AG <p.herz@...fihost.ag> To: Eric Dumazet <eric.dumazet@...il.com> CC: David Rientjes <rientjes@...gle.com>, Andi Kleen <andi@...stfloor.org>, s.priebe@...fihost.ag, linux-kernel@...r.kernel.org Subject: Re: Vanilla-Kernel 3 - page allocation failure Am 24.10.2011 09:03, schrieb Eric Dumazet: > Le lundi 24 octobre 2011 à 08:33 +0200, Philipp Herz - Profihost AG a > écrit : >> Am 19.10.2011 03:58, schrieb David Rientjes: >>> On Tue, 18 Oct 2011, Andi Kleen wrote: >>> >>>> Philipp Herz - Profihost AG<p.herz@...fihost.ag> writes: >>>> >>>>> After updating kernel (x86_64) to stable version 3 there are a few >>>>> messages appearing in the kernel log such as >>>>> >>>>> kworker/0:1: page allocation failure: order:1, mode:0x20 >>>>> mysql: page allocation failure: order:1, mode:0x20 >>>>> php5: page allocation failure: order:1, mode:0x20 >>>> >>>> You just ran out of memory. >>>> >>> >>> He ran out of order-1 physically contiguous memory and was unable to >>> compact or reclaim because of the atomic context. >>> >>> Philipp, based on your pastes from another post, it's evident you're using >>> CONFIG_SLAB and, unfortunately, it's not possible to change to single >>> page allocations (which would only result in a page allocation failure if >>> you were completely out of memory) without recompiling. >>> >>> You have a couple options: >>> >>> - recompile with BREAK_GFP_ORDER_HI redefined to 0 in mm/slab.c, or >>> >>> - recompile with CONFIG_SLUB instead of CONFIG_SLAB. >>> >>> It's very possible that neither of these will help, but it will tell you >>> whether you need to go out and buy more RAM or not. If you try to >>> recompile with BREAK_GFP_ORDER_HI, these may turn into order-0 >>> allocations. If you can't reboot, send the output of >>> /proc/<pid>/net/protocols where<pid> is the pid of one of the above tasks >>> (kworker, mysql, php5) when they are running and we'll know. >>> >>> [ Changing slab_break_gfp_order should really be a CONFIG_SLAB command- >>> line option. It can't be runtime because slab depends on the order for >>> caches remaining constant, but we can certainly change it on boot. ] >>> >>> If you try CONFIG_SLUB instead of CONFIG_SLAB, you can pass >>> slub_max_order=0 on the command line and see if it helps. >> >> Hi David, >> >> we have recompiled the kernel of one machine with CONFIG_SLUB instead of >> CONFIG_SLAB, but it is showing similar message. >> >> Now it's showing failure at "order:5, mode:0x4020". >> >> Call trace can be found at: >> * http://pastebin.com/uGJiwvG1 >> >> Comparing kernel 2.6.32 (mm/page_alloc.c) there seams to be the same way >> of dealing with page allocation. >> >> Do you have an idea why these (warning) messages do never appear running >> 2.6.32? > > Your tg3 has a firmware limitation, and some skbs using fragments have > to be reallocated using a single and contiguous area of memory. > > Initial skb delivered by tcp stack only uses order-0 pages, but the > reallocated one, being 64K, can be order-5 > > You can avoid this by following tuning : > > ethtool -K eth0 sg off > ok, does that mean that there was no firmware limitation with kernel 2.6.32 or that the tg3 module has any "disable warnings" flag matching __GFP_NOWARN? -- 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