There is a case in connected UDP socket such that
getsockopt(IPV6_MTU) will return a stale MTU value. The reproducible
sequence could be the following:
1. Create a connected UDP socket
2. Send some datagrams out
3. Receive a ICMPV6_PKT_TOOBIG
4. No new outgoing datagrams to trigger the sk_dst_check
On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote:
> + bh_lock_sock(sk);
> + if (!sock_owned_by_user(sk))
> + ip6_datagram_dst_update(sk, false);
> + bh_unlock_sock(sk);
My discussion with Eric shows that we probably don't need to hold
this sock lock here, an
On Fri, Apr 1, 2016 at 4:13 PM, Cong Wang wrote:
> On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote:
>> + bh_lock_sock(sk);
>> + if (!sock_owned_by_user(sk))
>> + ip6_datagram_dst_update(sk, false);
>> + bh_unlock_sock(sk);
>
>
> My discussion with Eric shows
On Fri, Apr 01, 2016 at 04:13:41PM -0700, Cong Wang wrote:
> On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote:
> > + bh_lock_sock(sk);
> > + if (!sock_owned_by_user(sk))
> > + ip6_datagram_dst_update(sk, false);
> > + bh_unlock_sock(sk);
>
>
> My discussion wi
On Sat, Apr 2, 2016 at 7:33 PM, Martin KaFai Lau 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
From: Cong Wang
Date: Mon, 4 Apr 2016 13:45:02 -0700
> On Sat, Apr 2, 2016 at 7:33 PM, Martin KaFai Lau 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_conne
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 up
On Tue, Apr 5, 2016 at 5:11 PM, Martin KaFai Lau 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
On Wed, Apr 06, 2016 at 10:58:23AM -0700, Cong Wang wrote:
> On Tue, Apr 5, 2016 at 5:11 PM, Martin KaFai Lau 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
On Wed, Apr 6, 2016 at 11:49 AM, Martin KaFai Lau wrote:
> On Wed, Apr 06, 2016 at 10:58:23AM -0700, Cong Wang wrote:
>> On Tue, Apr 5, 2016 at 5:11 PM, Martin KaFai Lau wrote:
>> > On Mon, Apr 04, 2016 at 01:45:02PM -0700, Cong Wang wrote:
>> >> I see your point, but calling __ip6_datagram_conne
On Thu, Apr 07, 2016 at 11:37:10AM -0700, Cong Wang wrote:
> You are lost in discussion
Indeed. :(
>
> I still think it is okay without the lock, because even if you take the lock,
> the pmtu update could still happen after you release it, so there is no
> essential difference here. The only reaso
On Tue, Apr 05, 2016 at 07:56:54PM -0400, David Miller wrote:
> From: Cong Wang
> Date: Mon, 4 Apr 2016 13:45:02 -0700
>
> > On Sat, Apr 2, 2016 at 7:33 PM, Martin KaFai Lau wrote:
> >> One thing to note is that this patch uses the addresses from the sk
> >> instead of iph when updating sk->sk_ds
12 matches
Mail list logo
