On Wed, May 30, 2018 at 10:28:42AM +0200, Nicolas Dichtel wrote: > After commit f6cc9c054e77, the following conf is broken (note that the > default loopback mtu is 65536, ie IP_MAX_MTU + 1): > > $ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev lo > add tunnel "gre0" failed: Invalid argument > $ ip l a type dummy > $ ip l s dummy1 up > $ ip l s dummy1 mtu 65535 > $ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev dummy1 > add tunnel "gre0" failed: Invalid argument > > dev_set_mtu() doesn't allow to set a mtu which is too large. > First, let's cap the mtu returned by ip_tunnel_bind_dev(). Second, remove > the magic value 0xFFF8 and use IP_MAX_MTU instead. > 0xFFF8 seems to be there for ages, I don't know why this value was used. > > With a recent kernel, it's also possible to set a mtu > IP_MAX_MTU: > $ ip l s dummy1 mtu 66000 > After that patch, it's also possible to bind an ip tunnel on that kind of > interface. > > CC: Petr Machata <pe...@mellanox.com> > CC: Ido Schimmel <ido...@mellanox.com> > Link: > https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a > Fixes: f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes") > Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com>
Reviewed-by: Ido Schimmel <ido...@mellanox.com> There is another instance of this magic number in the file, but it's written in lower case so you might have missed it - see ip_tunnel_newlink(). Can you please take care of it in v2? Thanks for the fix, Nicolas!