linux-kernel - Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger

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: <20220223112618.GA19531@debian.home>
Date:   Wed, 23 Feb 2022 12:26:18 +0100
From:   Guillaume Nault <gnault@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Vasily Averin <vvs@...tuozzo.com>,
        Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: vlan: allow vlan device MTU change follow real
 device from smaller to bigger

On Tue, Feb 22, 2022 at 03:28:15PM -0800, Jakub Kicinski wrote:
> On Tue, 22 Feb 2022 11:37:33 +0100 Guillaume Nault wrote:
> > What about an explicit option:
> > 
> >   ip link add link eth1 dev eth1.100 type vlan id 100 follow-parent-mtu
> > 
> > 
> > Or for something more future proof, an option that can accept several
> > policies:
> > 
> >   mtu-update <reduce-only,follow,...>
> > 
> >       reduce-only (default):
> >         update vlan's MTU only if the new MTU is smaller than the
> >         current one (current behaviour).
> > 
> >       follow:
> >         always follow the MTU of the parent device.
> > 
> > Then if anyone wants more complex policies:
> > 
> >       follow-if-not-modified:
> >         follow the MTU of the parent device as long as the VLAN's MTU
> >         was not manually changed. Otherwise only adjust the VLAN's MTU
> >         when the parent's one is set to a smaller value.
> > 
> >       follow-if-not-modified-but-not-quite:
> >         like follow-if-not-modified but revert back to the VLAN's
> >         last manually modified MTU, if any, whenever possible (that is,
> >         when the parent device's MTU is set back to a higher value).
> >         That probably requires the possibility to dump the last
> >         modified MTU, so the administrator can anticipate the
> >         consequences of modifying the parent device.
> > 
> >      yet-another-policy (because people have a lot of imagination):
> >        for example, keep the MTU 4 bytes lower than the parent device,
> >        to account for VLAN overhead.
> > 
> > Of course feel free to suggest better names and policies :).
> > 
> > This way, we can keep the current behaviour and avoid unexpected
> > heuristics that are difficult to explain (and even more difficult for
> > network admins to figure out on their own).
> 
> My $0.02 would be that if we want to make changes that require new uAPI
> we should do it across uppers.

Do you mean something like:

  ip link set dev eth0 vlan-mtu-policy <policy-name>

that'd affect all existing (and future) vlans of eth0?

Then I think that for non-ethernet devices, we should reject this
option and skip it when dumping config. But yes, that's another
possibility.

I personnaly don't really mind, as long as we keep a clear behaviour.

What I'd really like to avoid is something like:
  - By default it behaves this way.
  - If you modified the MTU it behaves in another way
  - But if you modified the MTU but later restored the
    original MTU, then you're back to the default behaviour
    (or not?), unless the MTU of the upper device was also
    changed meanwhile, in which case ... to be continued ...
  - BTW, you might not be able to tell how the VLAN's MTU is going to
    behave by simply looking at its configuration, because that also
    depends on past configurations.
  - Well, and if your kernel is older than xxx, then you always get the
    default behaviour.
  - ... and we might modify the heuristics again in the future to
    accomodate with situations or use cases we failed to consider.