netdev - Re: [RFC PATCH] tcp: limit data skbs in qdisc layer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1341845722.3265.3065.camel@edumazet-glaptop>
Date:	Mon, 09 Jul 2012 16:55:22 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	ycheng@...gle.com, dave.taht@...il.com, netdev@...r.kernel.org,
	codel@...ts.bufferbloat.net, therbert@...gle.com,
	mattmathis@...gle.com, nanditad@...gle.com, ncardwell@...gle.com,
	andrewmcgr@...il.com
Subject: Re: [RFC PATCH] tcp: limit data skbs in qdisc layer

On Mon, 2012-07-09 at 00:08 -0700, David Miller wrote:

> I'm suspicious and anticipate that 10G will need more queueing than
> you are able to get away with tg3 at 1G speeds.  But it is an exciting
> idea nonetheless :-)

There is a fundamental problem calling any xmit function from skb
destructor.

skb destructor can be called while qdisc lock is taken, so we can
deadlock trying to reacquire it.

One such path is the dev_deactivate_queue() -> qdisc_reset() ->
qdisc_reset_queue(), but also any dropped skbs in qdisc.

So I should only do this stuff from a separate context, for example a
tasklet or timer.

Alternative would be to use dev_kfree_skb_irq() for all dropped skbs in
qdisc layer.

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