Thread (29 messages) 29 messages, 5 authors, 2013-04-04

Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking

From: David Miller <davem@davemloft.net>
Date: 2013-03-29 19:23:00

From: Jesper Dangaard Brouer <redacted>
Date: Fri, 29 Mar 2013 20:01:33 +0100
On Fri, 2013-03-29 at 01:33 +0100, Hannes Frederic Sowa wrote:
quoted
On Thu, Mar 28, 2013 at 04:39:42PM -0700, Eric Dumazet wrote:
quoted
On Fri, 2013-03-29 at 00:30 +0100, Hannes Frederic Sowa wrote:
quoted
On Thu, Mar 28, 2013 at 01:22:44PM -0700, Eric Dumazet wrote:
quoted
On Thu, 2013-03-28 at 19:57 +0100, Hannes Frederic Sowa wrote:
quoted
I assume that it has to do with the usage of this code in
ipv6/netfilter/nf_conntrack_reasm.c, which could be invoked from process
context, if I read it correctly.
Then there would be a possible deadlock in current code.
Netfilter currently does a local_bh_disable() before entering inet_fragment
(and later enables it, again).
Good, so no need for the _bh() as I suspected.
Ack.

I replaced the _bh spin_locks with plain spinlocks and tested the code
with sending fragments and receiving fragments (netfilter and reassmbly
logic) with lockdep and didn't get any splats. Looks good so far.
Well, it's great to see, that you are working on solving my patch
proposal.  While I'm on Easter vacation ;-)  Much appreciated.
I'm officially back from vacation Tuesday, and I'll repost then (after
testing it on my 10G testlab).
Jesper, when you do this, please just put the whole of the excellent
description text you had in the "0/3" posting from this series into
the commit message for the respun patch #3.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help