Re: [PATCH net-next v2] net: clean up locking in inet_frag_find()

[Cong Wang <amwang@redhat.com>]

On Mon, 2012-11-26 at 07:12 -0800, Eric Dumazet wrote:
> On Mon, 2012-11-26 at 15:26 +0800, Cong Wang wrote:
> > It is weird to take the read lock outside of inet_frag_find()
> > but release it inside...  This can be improved by refactoring
> > the code, that is, introducing inet{4,6}_frag_find() which call
> > the their own hash function, inet{4,6}_hash_frag(), hiding the
> > details from their callers.
> > 
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Patrick McHardy <kaber@trash.net>
> > Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Cong Wang <amwang@redhat.com>
> > 
> > ---
> >  include/net/inet_frag.h                 |   17 +++++-
> >  include/net/ipv6.h                      |    3 -
> >  net/ipv4/inet_fragment.c                |   82 +++++++++++++++++++++++++++++--
> >  net/ipv4/ip_fragment.c                  |   16 +-----
> >  net/ipv6/netfilter/nf_conntrack_reasm.c |    7 +--
> >  net/ipv6/reassembly.c                   |   34 +------------
> >  6 files changed, 97 insertions(+), 62 deletions(-)
> 
> 
> Not clear to me its a win, as it adds 35 LOC. Nobody really complained
> of this locking schem in the past.

Yeah, seems every people here is able to read any ugly code, except
me. :-)

> 
> Also Jesper is working on this stuff, so you dont really ease its work.
> 
> 

I will rebase his tree for him, no worry, handling conflicts is part of
my life everyday (I am a heavy `git rebase -i` user).