netdev - Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU

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]

Date:   Mon, 21 Oct 2019 16:27:51 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     <davem@...emloft.net>, <dsahern@...il.com>, <jiri@...lanox.com>,
        <allison@...utok.net>, <mmanning@...tta.att-mail.com>,
        <petrm@...lanox.com>, <dcaratti@...hat.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when
 setting initial MTU

On Mon, 21 Oct 2019 20:26:03 +0800
Yunsheng Lin <linyunsheng@...wei.com> wrote:

> Currently the MTU of vlan netdevice is set to the same MTU
> of the lower device, which requires the underlying device
> to handle it as the comment has indicated:
> 
> 	/* need 4 bytes for extra VLAN header info,
> 	 * hope the underlying device can handle it.
> 	 */
> 	new_dev->mtu = real_dev->mtu;
> 
> Currently most of the physical netdevs seems to handle above
> by reversing 2 * VLAN_HLEN for L2 packet len.
> 
> But for vlan netdev over vxlan netdev case, the vxlan does not
> seems to reverse the vlan header for vlan device, which may cause
> performance degradation because vxlan may emit a packet that
> exceed the MTU of the physical netdev, and cause the software
> TSO to happen in ip_finish_output_gso(), software TSO call stack
> as below:
> 
>  => ftrace_graph_call
>  => tcp_gso_segment
>  => tcp4_gso_segment
>  => inet_gso_segment
>  => skb_mac_gso_segment
>  => skb_udp_tunnel_segment
>  => udp4_ufo_fragment
>  => inet_gso_segment
>  => skb_mac_gso_segment
>  => __skb_gso_segment
>  => __ip_finish_output
>  => ip_output
>  => ip_local_out
>  => iptunnel_xmit
>  => udp_tunnel_xmit_skb
>  => vxlan_xmit_one
>  => vxlan_xmit
>  => dev_hard_start_xmit
>  => __dev_queue_xmit
>  => dev_queue_xmit
>  => vlan_dev_hard_start_xmit
>  => dev_hard_start_xmit
>  => __dev_queue_xmit
>  => dev_queue_xmit
>  => neigh_resolve_output
>  => ip_finish_output2
>  => __ip_finish_output
>  => ip_output
>  => ip_local_out
>  => __ip_queue_xmit
>  => ip_queue_xmit
>  => __tcp_transmit_skb
>  => tcp_write_xmit
>  => __tcp_push_pending_frames
>  => tcp_push
>  => tcp_sendmsg_locked
>  => tcp_sendmsg
>  => inet_sendmsg
>  => sock_sendmsg
>  => sock_write_iter
>  => new_sync_write
>  => __vfs_write
>  => vfs_write
>  => ksys_write
>  => __arm64_sys_write
>  => el0_svc_common.constprop.0
>  => el0_svc_handler
>  => el0_svc  
> 
> This patch set initial MTU of the vlan device to the MTU of the
> lower device minus vlan header to handle the above case.
> 
> Signed-off-by: Yunsheng Lin <linyunsheng@...wei.com>

The MTU is visible to user space in many tools, and Linux (and BSD)
have always treated VLAN header as not part of the MTU. You can't change
that now.