netdev - Re: [PATCH] net:bridge:always disable auto-tuning when the user specified 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] [day] [month] [year] [list]

Message-ID: <CAKx2cEQCm4WrE7eu4+Q7Yc8QLB45fAjjiQdBNBvhWZZcridVTg@mail.gmail.com>
Date:   Tue, 16 Apr 2019 15:19:23 +0800
From:   黄睿 <huangruippp@...il.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     Petr Machata <petrm@...lanox.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "hawk@...nel.org" <hawk@...nel.org>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "kafai@...com" <kafai@...com>,
        "songliubraving@...com" <songliubraving@...com>,
        "yhs@...com" <yhs@...com>, Jiri Pirko <jiri@...lanox.com>,
        "ecree@...arflare.com" <ecree@...arflare.com>,
        Ido Schimmel <idosch@...lanox.com>,
        "alexander.h.duyck@...el.com" <alexander.h.duyck@...el.com>,
        "amritha.nambiar@...el.com" <amritha.nambiar@...el.com>,
        Li Rongqing <lirongqing@...du.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "xdp-newbies@...r.kernel.org" <xdp-newbies@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
        "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>
Subject: Re: [PATCH] net:bridge:always disable auto-tuning when the user
 specified MTU

Whether use the current method to configure bridge's MTU or
add a notification in bridge's internal code and send a notification
when modify the bridge's MTU, we all need to add an additional
judgement in dev_set_mtu_ext's first if statement for bridge to
let the process not return early.

By the way, whether it is the expected result or the current result,
the MTU of the bridge will not be larger than the interface in the bridge.
Which scene will cause frame drop.

Nikolay Aleksandrov <nikolay@...ulusnetworks.com> 于2019年4月10日周三 下午7:05写道：
>
> On 10/04/2019 13:34, Petr Machata wrote:
> >
> > Stephen Hemminger <stephen@...workplumber.org> writes:
> >
> >> On Wed, 10 Apr 2019 02:32:08 +0000
> >> Huang Rui <huangruippp@...il.com> wrote:
> >>
> >>> For example.
> >>> My purpose is to create a bridge br0 and join eth0 into br0.
> >>> if we use this following way, the auto-tuning flag will not be disabled.
> >>>
> >>> If eth0's mtu is 1200
> >>> step 1.brctl addbr br0
> >>> step 2.brctl addif br0 eth0
> >>> step 3.ifconfig br0 mtu 1200
> >>> step 4.ifconfig eth0 mtu 1500
> >>>
> >>> Result:
> >>> br0's MTU: 1500, eth0's MTU: 1500
> >>>
> >>> Expected:
> >>> br0's MTU: 1200, eth0's MTU: 1500
> >>>
> >>> I have specified br0's MTU,  but auto-min policy works. So the MTU is
> >>> not the result what we expected.
> >>> As expected, if i have specified bridge's MTU, it will set the flag:
> >>> BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
> >>> policy will not work.But in this case, because the dev_set_mtu return
> >>> early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
> >>> auto-min/max policy will still work.
> >>>
> >>> Signed-off-by: Huang Rui <huangruiPPP@...il.com>
> >>
> >> A bridge like this going to drop frames.
> >> A frame received with MTU of 1200 will get dropped.
> >
> > That's true even if above you set br0's MTU to 1201, but then the
> > auto-tuning is disabled as expected. The problem is that setting MTU to
> > 1200 is perceived as a non-change, whereas it should instead be
> > perceived as a signal that the user takes over the MTU management.
> >
> >> The proper way to do this is to change MTU of both interfaces to match.
>
> The only problem is a lot of the network configuration software these days
> sets the MTU by default and that would lead to disabling auto-tune by default.
> And since you haven't received a notification it means nothing has changed,
> but in this case state has changed for the bridge quietly. It could break setups
> which rely on the auto-tune and it would do it quietly which won't be easy to debug.
>
> Also as I said in my previously, I really don't like adding bridge-specific
> code in there. Another more ambitious approach would be to maybe always pass the
> value to the drivers and let them deal with it, that would require going through all
> ndo_change_mtu users and also would still not solve the problem of not sending
> a notification when there has been a state change (the bridge no longer auto-tunes).
> Thus the bridge will probably have to emit *some* notification by itself.
>
> Perhaps this should've been a bridge option from the start instead of automatic
> decision but it's late for that now.
>
> Thanks,
>  Nik