[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 13:45:02 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Martin KaFai Lau <kafai@...com>
Cc: netdev <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>,
Wei Wang <weiwan@...gle.com>, Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a
connected datagram sk during pmtu update
On Sat, Apr 2, 2016 at 7:33 PM, Martin KaFai Lau <kafai@...com> wrote:
> One thing to note is that this patch uses the addresses from the sk
> instead of iph when updating sk->sk_dst_cache. It is basically the
> same logic that the __ip6_datagram_connect() is doing, so some
> refactoring works in the first two patches.
>
> AFAIK, a UDP socket can become connected after sending out some
> datagrams in un-connected state. or It can be connected
> multiple times to different destinations. I did some quick
> tests but I could be wrong.
>
> I am thinking if there could be a chance that the skb->data, which
> has the original outgoing iph, is not related to the current
> connected address. If it is possible, we have to specifically
> use the addresses in the sk instead of skb->data (i.e. iph) when
> updating the sk->sk_dst_cache.
>
> If we need to use the sk addresses (and other info) to find out a
> new dst for a connected udp socket, it is better not doing it while
> the userland is connecting to somewhere else.
>
> If the above case is impossible, we can keep using the info from iph to
> do the dst update for a connected-udp sk without taking the lock.
I see your point, but calling __ip6_datagram_connect() seems overkill
here, we don't need to update so many things in the pmtu update context,
at least IPv4 doesn't do that either. I don't think you have to do that.
So why just updating the dst cache (also some addr cache) here is not
enough?
Powered by blists - more mailing lists