linux-kernel - Re: netconsole: tulip: possible remote DoS? due to kernel freeze on heavy RX traffic after Order-1 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: <1257484384.2873.618.camel@calx>
Date:	Thu, 05 Nov 2009 23:13:04 -0600
From:	Matt Mackall <mpm@...enic.com>
To:	Tobias Diedrich <ranma@...edrich.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: netconsole: tulip: possible remote DoS? due to kernel freeze
 on heavy RX traffic after Order-1 allocation failure

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


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