[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1364583693.3232.257.camel@localhost>
Date: Fri, 29 Mar 2013 20:01:33 +0100
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Florian Westphal <fw@...len.de>,
Daniel Borkmann <dborkman@...hat.com>
Subject: Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking
On Fri, 2013-03-29 at 01:33 +0100, Hannes Frederic Sowa wrote:
> On Thu, Mar 28, 2013 at 04:39:42PM -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-29 at 00:30 +0100, Hannes Frederic Sowa wrote:
> > > On Thu, Mar 28, 2013 at 01:22:44PM -0700, Eric Dumazet wrote:
> > > > On Thu, 2013-03-28 at 19:57 +0100, Hannes Frederic Sowa wrote:
> > > >
> > > > > 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
--
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
Powered by blists - more mailing lists