netdev - Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev 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]

Message-ID: <20220614142737.73fffc9d@elisabeth>
Date:   Tue, 14 Jun 2022 14:27:37 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com>,
        Kaustubh Pandey <quic_kapandey@...cinc.com>
Cc:     <davem@...emloft.net>, <dsahern@...nel.org>,
        <yoshfuji@...ux-ipv6.org>, <kuba@...nel.org>,
        <netdev@...r.kernel.org>,
        Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit
 of dev mtu

Hi Kaustubh,

On Mon, 13 Jun 2022 23:01:54 -0600
Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com> wrote:

> From: Kaustubh Pandey <quic_kapandey@...cinc.com>
> 
> When netdevice MTU is increased via sysfs, NETDEV_CHANGEMTU is raised.
> 
> addrconf_notify -> rt6_mtu_change -> rt6_mtu_change_route ->
> fib6_nh_mtu_change
> 
> As part of handling NETDEV_CHANGEMTU notification we land up on a
> condition where if route mtu is less than dev mtu and route mtu equals
> ipv6_devconf mtu, route mtu gets updated.
> 
> Due to this v6 traffic end up using wrong MTU then configured earlier.

I read this a few times but I still fail to understand what issue
you're actually fixing -- what makes this new MTU "wrong"?

The idea behind the original implementation is that, when an interface
MTU is administratively updated, we should allow PMTU updates, if the
old PMTU was matching the interface MTU, because the old MTU setting
might have been the one limiting the MTU on the whole path.

That is, if you lower the MTU on an interface, and then increase it
back, a permanently lower PMTU is somewhat unexpected. As far as I can
see, this behaviour persists with this patch, but:

> This commit fixes this by removing comparison with ipv6_devconf
> and updating route mtu only when it is greater than incoming dev mtu.

...I'm not sure what you really mean by "incoming dev mtu". Is it the
newly configured one?

-- 
Stefano