netdev - Re: [PATCH] bridge: increase mtu to 64K

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:   Thu, 7 May 2020 14:06:22 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Michael Braun <michael-dev@...i-braun.de>, netdev@...r.kernel.org
Cc:     Li RongQing <roy.qing.li@...il.com>
Subject: Re: [PATCH] bridge: increase mtu to 64K

On 07/05/2020 13:32, Michael Braun wrote:
> A linux bridge always adopts the smallest MTU of the enslaved devices.
> When no device are enslaved, it defaults to a MTU of 1500 and refuses to
> use a larger one. This is problematic when using bridges enslaving only
> virtual NICs (vnetX) like it's common with KVM guests.
> 
> Steps to reproduce the problem
> 
> 1) sudo ip link add br-test0 type bridge # create an empty bridge
> 2) sudo ip link set br-test0 mtu 9000 # attempt to set MTU > 1500
> 3) ip link show dev br-test0 # confirm MTU
> 
> Here, 2) returns "RTNETLINK answers: Invalid argument". One (cumbersome)
> way around this is:
> 
> 4) sudo modprobe dummy
> 5) sudo ip link set dummy0 mtu 9000 master br-test0
> 
> Then the bridge's MTU can be changed from anywhere to 9000.
> 
> This is especially annoying for the virtualization case because the
> KVM's tap driver will by default adopt the bridge's MTU on startup
> making it impossible (without the workaround) to use a large MTU on the
> guest VMs.
> 

Hi Michael,
That isn't correct, have you tested with a recent kernel?
After:
commit 804b854d374e
Author: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Date:   Fri Mar 30 13:46:19 2018 +0300

    net: bridge: disable bridge MTU auto tuning if it was set manually

You can set the bridge MTU to anything before adding ports.

E.g.:
$ ip l add br1 type bridge
$ ip l set br1 mtu 65000
$ ip l sh dev br1
12: br1: <BROADCAST,MULTICAST> mtu 65000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b6:ad:91:dc:5f:39 brd ff:ff:ff:ff:ff:ff

And a second one (ens17, ens18 with MTU 1500, br0 new with MTU 1500):
$ ip l set ens17 master br0
$ ip l set ens18 master br0
$ ip l set br0 mtu 65000
$ ip l sh dev br0
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:ed:3f:df:94:1f brd ff:ff:ff:ff:ff:ff
$ ip l sh dev ens17
8: ens17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:23:5f:13 brd ff:ff:ff:ff:ff:ff

 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064
> 
> Signed-off-by: Michael Braun <michael-dev@...i-braun.de>
> Reported-by: Li RongQing <roy.qing.li@...il.com>
> 
> --
> If found https://patchwork.ozlabs.org/project/netdev/patch/1456133351-10292-1-git-send-email-roy.qing.li@gmail.com/
> but I am missing any follow up. So here comes a refresh patch that
> addresses the issue raised.
> ---
>  net/bridge/br_if.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index 4fe30b182ee7..f14e7d2329bd 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -496,7 +496,7 @@ static int br_mtu_min(const struct net_bridge *br)
>  		if (!ret_mtu || ret_mtu > p->dev->mtu)
>  			ret_mtu = p->dev->mtu;
>  
> -	return ret_mtu ? ret_mtu : ETH_DATA_LEN;
> +	return ret_mtu ? ret_mtu : (64 * 1024);
>  }
>  
>  void br_mtu_auto_adjust(struct net_bridge *br)
> 
Please CC bridge maintainers on bridge patches.
Note that there's a mechanism in the bridge to disable auto-MTU tuning if the user *changes*
the MTU manually (it's important the MTU actually changes by the op). The auto-tuning has
been a constant headache.

The patch also has a problem - it sets the MTU over ETH_MAX_MTU (65535).

Cheers,
 Nik