lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171219.133837.595373033883352504.davem@davemloft.net>
Date:   Tue, 19 Dec 2017 13:38:37 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     lucien.xin@...il.com
Cc:     netdev@...r.kernel.org, jbenc@...hat.com
Subject: Re: [PATCH net] vxlan: update skb dst pmtu on tx path

From: Xin Long <lucien.xin@...il.com>
Date: Wed, 20 Dec 2017 01:05:32 +0800

> On Wed, Dec 20, 2017 at 12:12 AM, David Miller <davem@...emloft.net> wrote:
>> You're going to have to find a way to fix this without
>> invoking ->update_pmtu() on every single transmit.  That's
>> really excessive, especially for an operation which is
>> going to be a NOP %99.9999 of the time.
> understand, I couldn't find a better way,  and all iptunnels are
> doing it in this way.
> 
> Or is it possible to go with an unlikely here ?
> 
>                 if (unlikely(skb_dst(skb) && mtu < dst_mtu(skb_dst(skb))))
>                         skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
>                                                        skb, mtu);
> 
> 
 ...
> how about doing it in vxlan_get_route():
> @@ -1896,6 +1896,13 @@ static struct rtable *vxlan_get_route(struct
> vxlan_dev *vxlan, struct net_device
>                 *saddr = fl4.saddr;
>                 if (use_cache)
>                         dst_cache_set_ip4(dst_cache, &rt->dst, fl4.saddr);
> +
> +               if (skb_dst(skb)) {
> +                       int mtu = dst_mtu(ndst) - VXLAN_HEADROOM;
> +
> +                       skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
> +                                                      skb, mtu);
> +               }
> 
> 
> This would do it only when no dst_cache and it has to do real route lookup.
> 
> Note that even when update_pmtu is hit, mostly it will do nothing and
> just return
> as usually new mtu >= skb_dst(skb)'s pmtu.

Ok, yeah, this is really difficult.

I'll apply your patch for now, but generally speaking we have to handle this
issue better.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ