Messages in this thread | | | Subject | Re: netconsole: tulip: possible remote DoS? due to kernel freeze on heavy RX traffic after Order-1 allocation failure | From | Matt Mackall <> | Date | Thu, 05 Nov 2009 23:13:04 -0600 |
| |
On Fri, 2009-11-06 at 04:27 +0100, Tobias Diedrich wrote: > Matt Mackall wrote: > > > Example from netconsole log: > > > |perl: page allocation failure. order:1, mode:0x20 > > > |Pid: 3541, comm: perl Tainted: G W 2.6.30.9-tomodachi #16 > > > |Call Trace: > > > | [<c013e56d>] ? __alloc_pages_internal+0x353/0x36f > > > | [<c0154f2c>] ? cache_alloc_refill+0x2ab/0x544 > > > | [<c0355479>] ? dev_alloc_skb+0x11/0x25 > > > | [<c015526f>] ? __kmalloc_track_caller+0xaa/0xf9 > > > | [<c0354ae5>] ? __alloc_skb+0x48/0xff > > > | [<c0355479>] ? dev_alloc_skb+0x11/0x25 > > > | [<c02d4ba9>] ? tulip_refill_rx+0x3c/0x115 > > > | [<c02d4fff>] ? tulip_poll+0x37d/0x416 > > > | [<c0359763>] ? net_rx_action+0x6b/0x12f > > > | [<c0121ad7>] ? __do_softirq+0x4e/0xbf > > > | [<c0121a89>] ? __do_softirq+0x0/0xbf > > > | <IRQ> [<c0107700>] ? do_IRQ+0x53/0x63 > > > | [<c0106610>] ? common_interrupt+0x30/0x38 > > > > I don't see anything in this trace to implicate netconsole? This is the > > normal network receive path running out of input buffers then running > > into memory fragmentation. > > I'm just thinking the hang might be related to using netconsole. > I guess I should try reproducing it without it.
You should, though I'd be surprised if it matters.
> Or is it normal that a box will hang if the network receive path runs out of > input buffers?
No, it's not normal.
> Why does it allocate Order-1 buffers anyway?
Your skbs are allocated via the SLAB allocator, which packs 5 skbs into an order-1 buffer rather than 4 into 2 order-0 buffers.
Running out of order-1 buffers hasn't been a problem for most people lately though - is there anything interesting about your workload? Lots of threads? NFS? Long network processing latencies?
-- http://selenic.com : development and support for Mercurial and Linux
| |