[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1410994109.2154471.168778833.586B4173@webmail.messagingengine.com>
Date: Thu, 18 Sep 2014 00:48:29 +0200
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Nicolas Dichtel <nicolas.dichtel@...nd.com>, netdev@...r.kernel.org
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Vlad Yasevich <vyasevich@...il.com>
Subject: Re: [PATCH RFC 1/6] ipv6: also increase fib6_node sernum on deletion
events
On Tue, Sep 16, 2014, at 18:18, Nicolas Dichtel wrote:
> Le 12/09/2014 01:21, Hannes Frederic Sowa a écrit :
> > fib6_add increases the fn_sernum of fib6_nodes while it traverses the
> > tree. This serial number is used by ip6_dst_check to judge whether a
> > relookup for the socket cache should be done (e.g. a better route is
> > available).
> >
> > We didn't do so for fib6_del, so we missed relookups on ipv6 address
> > deletion events. Because this caused trouble in the SCTP stack, instead
> > the genid for ipv6 was bumped. Also TCP connections used old source
> > addresses, which were not available anymore.
> >
> > Because we have static rt6_nodes in the tree (no RTF_GATEWAY,
> > RTF_NONEXTHOP nor RTF_CACHE nodes but still DST_HOST) flag, we ended up
> > in a situation where the genid of the routing node was always smaller
> > than the published genid in the namespace. That caused ip6_dst_check to
> > always discard the current dst_entry and a relookup happend.
> >
> > This patch prepares for the removal of the ipv6 genid by also modifying
> > the fn_sernum on route deletion.
> >
> > Thanks to Eric Dumazet who noticed this problem!
> >
> > Cc: Eric Dumazet <eric.dumazet@...il.com>
> > Cc: Vlad Yasevich <vyasevich@...il.com>
> > Cc: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>
> This serie looks good to me. Thank you for working on this topic!
I fear we still have to bump all fn_sernums on ipv6 address deletion
events, because the dst_check also implicitly checked for source address
notifications.
I have two approaches to solve this for the moment: we store the
ipv6.dev_addr_genid in the ipv6_pinfo or walk the whole tree or walk the
whole tree on device removal. Both approaches work here, one is faster
but ipv6 sockets need to be increased, other one needs to walk all nodes
on address removal.
Bye,
Hannes
--
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