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
| ||
|
Date: Thu, 28 Jan 2016 09:04:05 -0800 From: Mahesh Bandewar <maheshb@...gle.com> To: Eric Dumazet <edumazet@...gle.com> Cc: Mahesh Bandewar <mahesh@...dewar.net>, David Miller <davem@...emloft.net>, Tim Hockin <thockin@...gle.com>, netdev <netdev@...r.kernel.org>, Eric Dumazet <eric.dumazet@...il.com>, Tim Hockins <thockins@...gle.com> Subject: Re: [PATCH next] ipvlan: inherit MTU from master device On Thu, Jan 28, 2016 at 5:13 AM, Eric Dumazet <edumazet@...gle.com> wrote: > On Wed, Jan 27, 2016 at 11:33 PM, Mahesh Bandewar <mahesh@...dewar.net> wrote: >> From: Mahesh Bandewar <maheshb@...gle.com> >> >> When we create IPvlan slave; we use ether_setup() and that >> sets up default MTU to 1500 while the master device may have >> lower / different MTU. Any subsequent changes to the masters' >> MTU are reflected into the slaves' MTU setting. However if those >> don't happen (most likely scenario), the slaves' MTU stays at >> 1500 which could be bad. >> >> This change adds code to inherit MTU from the master device >> instead of using the default value during the link initialization >> phase. >> >> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com> >> CC: Eric Dumazet <eric.dumazet@...il.com> >> CC: Tim Hockins <thockins@...gle.com> >> > > Acked-by: Eric Dumazet <edumazet@...gle.com> > > Two points Mahesh : > > 1) ipvlan_adjust_mtu() could be static, it is only used from > drivers/net/ipvlan/ipvlan_main.c > Correct, I'm working on a some other (generic) changes and I could include this suggestion as part of that / later patch or do you prefer it to be part of this change? > 2) mtu_adj does not seem to be used ? mtu_adj is set to zero so that it follows the master. The idea behind this field was that if enhancements / changes to the IPvlan driver (some sort of built-in encapsulation etc.) is added, this can be set to that magic value so that changes to master will still allow slaves to follow it without compromising the built-in mechanism.
Powered by blists - more mailing lists