On Tue, Apr 5, 2016 at 5:11 PM, Martin KaFai Lau <ka...@fb.com> wrote: > On Mon, Apr 04, 2016 at 01:45:02PM -0700, Cong Wang wrote: >> 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? > I am not sure I understand. I could be missing something. > > This patch uses ip6_datagram_dst_update() to do the route lookup and > sk->sk_dst_cache update. ip6_datagram_dst_update() is > created in the first two refactoring patches and is also used by > __ip6_datagram_connect(). > > Which operations in ip6_datagram_dst_update() could be saved > during the pmtu update?
I thought you call the same ip6_datagram_dst_update() for both pmtu update and __ip6_datagram_connect(), but you actually skip some sk operations for pmtu case, which means you don't need to worry about parallel ip6_datagram_connect(). IPv6 UDP sendmsg() path stores the dst without sock lock anyway, we don't cope with a concurrent connect() on another cpu. But still, I don't see this is a problem here, because even if we store an obsolete address in cache, it would be corrected later.
