On Mon, Mar 28, 2016 at 03:39:42PM -0700, Cong Wang wrote:
> On Fri, Mar 25, 2016 at 5:16 PM, Martin KaFai Lau wrote:
> > On Fri, Mar 25, 2016 at 04:55:27PM -0700, Martin KaFai Lau wrote:
> >> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
> >> {
> >> + struct dst_
On Fri, Mar 25, 2016 at 5:16 PM, Martin KaFai Lau wrote:
> On Fri, Mar 25, 2016 at 04:55:27PM -0700, Martin KaFai Lau wrote:
>> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
>> {
>> + struct dst_entry *odst;
>> +
>> + odst = sk_dst_get(sk);
>> +
>> ip6_u
On Fri, Mar 25, 2016 at 04:55:27PM -0700, Martin KaFai Lau wrote:
> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
> {
> + struct dst_entry *odst;
> +
> + odst = sk_dst_get(sk);
> +
> ip6_update_pmtu(skb, sock_net(sk), mtu,
> sk->sk_b
On Wed, Mar 23, 2016 at 04:57:22PM -0700, Wei Wang wrote:
> What about something like this:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ed44663..21b4102 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1394,6 +1394,19 @@ static void ip6_rt_update_pmtu(struct dst_entry
On Thu, Mar 24, 2016 at 11:32:28AM -0700, Martin KaFai Lau wrote:
> Some fast path may do __sk_dst_get() which does not refcnt the
> sk->sk_dst_cache.
Ignore this comment. This should have been protected by rcu grace period.
On Tue, Mar 22, 2016 at 4:36 PM, Eric Dumazet wrote:
> On Tue, 2016-03-22 at 13:13 -0700, Cong Wang wrote:
>> On Tue, Mar 22, 2016 at 11:03 AM, Wei Wang wrote:
>> > Thanks Martin and Cong.
>> >
>> > I guess then we are going with the following fix in ip6_sk_update_pmtu():
>> > 1. call ip6_upate_p
On Wed, Mar 23, 2016 at 04:57:22PM -0700, Wei Wang wrote:
> What about something like this:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ed44663..21b4102 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1394,6 +1394,19 @@ static void ip6_rt_update_pmtu(struct dst_entry
What about something like this:
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ed44663..21b4102 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1394,6 +1394,19 @@ static void ip6_rt_update_pmtu(struct dst_entry
*dst, struct sock *sk,
__ip6_rt_update_pmtu(dst, sk, skb ? ipv6_hd
On Tue, 2016-03-22 at 13:13 -0700, Cong Wang wrote:
> On Tue, Mar 22, 2016 at 11:03 AM, Wei Wang wrote:
> > Thanks Martin and Cong.
> >
> > I guess then we are going with the following fix in ip6_sk_update_pmtu():
> > 1. call ip6_upate_pmtu() as it is
> > 2. do a dst_check()
> > 3. re-lookup() if
On Tue, Mar 22, 2016 at 11:03 AM, Wei Wang wrote:
> Thanks Martin and Cong.
>
> I guess then we are going with the following fix in ip6_sk_update_pmtu():
> 1. call ip6_upate_pmtu() as it is
> 2. do a dst_check()
> 3. re-lookup() if it is invalid
> 4. and then do a ip6_dst_store()/dst_set
Exactly,
On Tue, Mar 22, 2016 at 10:39 AM, Martin KaFai Lau wrote:
> On Tue, Mar 22, 2016 at 09:53:35AM -0700, Cong Wang wrote:
>> On Mon, Mar 21, 2016 at 11:02 PM, Martin KaFai Lau wrote:
>> > In term of difference, AFAICT, the current patch is an optimization in the
>> > sense that the update_pmtu() cod
On Tue, Mar 22, 2016 at 11:03:29AM -0700, Wei Wang wrote:
> But one thing here, we will have to generate the same flowi6 in both
> ip6_sk_update_pmtu() as well as ip6_update_pmtu(). Is this considered
> as a not clean enough fix?
If they share common codes to build flowi6, can the common codes
be f
Thanks Martin and Cong.
I guess then we are going with the following fix in ip6_sk_update_pmtu():
1. call ip6_upate_pmtu() as it is
2. do a dst_check()
3. re-lookup() if it is invalid
4. and then do a ip6_dst_store()/dst_set
But one thing here, we will have to generate the same flowi6 in both
ip6
On Tue, Mar 22, 2016 at 09:53:35AM -0700, Cong Wang wrote:
> On Mon, Mar 21, 2016 at 11:02 PM, Martin KaFai Lau wrote:
> > In term of difference, AFAICT, the current patch is an optimization in the
> > sense that the update_pmtu() code path does not have to do a dst_check to
> > discover its sk->s
On Mon, Mar 21, 2016 at 11:02 PM, Martin KaFai Lau wrote:
> I think Cong Wang is suggesting, in ip6_sk_update_pmtu():
> 1. call ip6_upate_pmtu() as it is
> 2. do a dst_check()
> 3. re-lookup() if it is invalid
> 4. and then do a ip6_dst_store()/dst_set
>
> The above is exactly what inet6_csk_updat
On Mon, Mar 21, 2016 at 10:13:41AM -0700, Wei Wang wrote:
> Hey Cong,
>
> This solution probably will not work.
> First of all, if you look into __ip6_rt_update_pmtu(), it creates a
> new dst and this dst does not get passed back to its caller. So unless
> we tweak this function to pass the new dst
Hey Cong,
This solution probably will not work.
First of all, if you look into __ip6_rt_update_pmtu(), it creates a
new dst and this dst does not get passed back to its caller. So unless
we tweak this function to pass the new dst back, we can only update
sk->sk_dst_cache inside the function itself
From: Eric Dumazet
Date: Wed, 16 Mar 2016 17:22:07 -0700
> One of the issue is that IPV6_MTU getsockopt() will not check the dst,
> but simply use __sk_dst_get() : It will then report old mtu.
That's a bug.
ipv4 does it right with a proper sk_dst_get() and so should
ipv6.
I don't think ip6_sk_update_pmtu() is a good place to put it as all it
does is to call ip6_update_pmtu(). And ip6_update_pmtu() does the
route lookup and call __ip6_rt_update_pmtu.
We can put it in ip6_update_pmtu(). But that still means we need to
pass sk to ip6_update_pmtu() and I don't think it
On Wed, Mar 16, 2016 at 8:34 PM, Eric Dumazet wrote:
> On Wed, 2016-03-16 at 22:38 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Wed, 16 Mar 2016 17:22:07 -0700
>>
>> > One of the issue is that IPV6_MTU getsockopt() will not check the dst,
>> > but simply use __sk_dst_get() : It will
On Wed, 2016-03-16 at 22:38 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 16 Mar 2016 17:22:07 -0700
>
> > One of the issue is that IPV6_MTU getsockopt() will not check the dst,
> > but simply use __sk_dst_get() : It will then report old mtu.
>
> That's a bug.
>
> ipv4 does it ri
On Mon, Mar 14, 2016 at 01:59:47PM -0700, Wei Wang wrote:
> From: Wei Wang
>
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
A nit picking, the new mtu value cannot always be set dire
From: Wei Wang
Date: Mon, 14 Mar 2016 13:59:47 -0700
> From: Wei Wang
>
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
> This leads to the issue that the mtu value returned by get
On Wed, 2016-03-16 at 19:53 -0400, David Miller wrote:
> From: Wei Wang
> Date: Mon, 14 Mar 2016 13:59:47 -0700
>
> > From: Wei Wang
> >
> > When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> > the new mtu value is not properly updated in the dst_entry associated
> > with t
On Fri, Mar 18, 2016 at 10:45 AM, Wei Wang wrote:
> Thanks all for the comments.
>
> Cong, you are right that for ipv6, the code does not take care of updating
> sk_dst_cache entry like Ipv4. And this patch is updating the entry by
> calling ip6_dst_store() to achieve similar functionality as Ipv4
On Fri, Mar 18, 2016 at 2:26 PM, Wei Wang wrote:
> I don't think ip6_sk_update_pmtu() is a good place to put it as all it
> does is to call ip6_update_pmtu(). And ip6_update_pmtu() does the
> route lookup and call __ip6_rt_update_pmtu.
> We can put it in ip6_update_pmtu(). But that still means we
From: Wei Wang
When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
the new mtu value is not properly updated in the dst_entry associated
with the socket.
This leads to the issue that the mtu value returned by getsockopt(sockfd,
IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
The fix is t
On Wed, Mar 02, 2016 at 11:19:21AM -0800, Wei Wang wrote:
> From: Wei Wang
>
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
> This leads to the issue that the mtu value returned by g
On Mon, Mar 7, 2016 at 9:19 AM, Eric Dumazet wrote:
> On Sat, Mar 5, 2016 at 9:55 PM, David Miller wrote:
>> From: Wei Wang
>> Date: Wed, 2 Mar 2016 11:19:21 -0800
>>
>>> @@ -566,7 +567,16 @@ void __udp6_lib_err(struct sk_buff *skb, struct
>>> inet6_skb_parm *opt,
>>> if (type == ICMPV6_
On Sat, Mar 5, 2016 at 9:55 PM, David Miller wrote:
> From: Wei Wang
> Date: Wed, 2 Mar 2016 11:19:21 -0800
>
>> @@ -566,7 +567,16 @@ void __udp6_lib_err(struct sk_buff *skb, struct
>> inet6_skb_parm *opt,
>> if (type == ICMPV6_PKT_TOOBIG) {
>> if (!ip6_sk_accept_pmtu(sk))
>
From: Wei Wang
Date: Wed, 2 Mar 2016 11:19:21 -0800
> @@ -566,7 +567,16 @@ void __udp6_lib_err(struct sk_buff *skb, struct
> inet6_skb_parm *opt,
> if (type == ICMPV6_PKT_TOOBIG) {
> if (!ip6_sk_accept_pmtu(sk))
> goto out;
> - ip6_sk_update
From: Wei Wang
When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
the new mtu value is not properly updated in the dst_entry associated
with the socket.
This leads to the issue that the mtu value returned by getsockopt(sockfd,
IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
The fix is t
32 matches
Mail list logo
