netdev - Re: [PATCH V2] ipvlan: fix ipvlan MTU limits

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: <CAF2d9jhbH=vFQvm4TZr9mXmMQpEFB9asSZsHFX_YMWKbT3YoVg@mail.gmail.com>
Date:   Thu, 11 Jan 2018 10:35:16 -0800
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     Jiri Benc <jbenc@...hat.com>
Cc:     liuqifa@...wei.com, David Miller <davem@...emloft.net>,
        dsahern@...il.com, mschiffer@...verse-factory.net,
        idosch@...lanox.com, fw@...len.de, kjlx@...pleofstupid.com,
        girish.moodalbail@...cle.com, sainath.grandhi@...el.com,
        linux-netdev <netdev@...r.kernel.org>, weiyongjun1@...wei.com,
        chenweilong@...wei.com, maowenan@...wei.com, wangyufen@...wei.com,
        yuehaibing@...wei.com, liujian56@...wei.com, liuzhe24@...wei.com,
        wangkefeng.wang@...wei.com, dingtianhong@...wei.com
Subject: Re: [PATCH V2] ipvlan: fix ipvlan MTU limits

On Thu, Jan 11, 2018 at 8:59 AM, Mahesh Bandewar (महेश बंडेवार)
<maheshb@...gle.com> wrote:
> On Thu, Jan 11, 2018 at 3:25 AM, Jiri Benc <jbenc@...hat.com> wrote:
>> On Wed, 10 Jan 2018 18:09:50 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
>>> I still prefer the approach I had mentioned that uses 'mtu_adj'. In
>>> that approach you can leave those slaves which have changed their mtu
>>> to be lower than masters' but if master's mtu changes to larger value
>>> all other slaves will get updated mtu leaving behind the slaves who
>>> have opted to change their mtu on their own. Also the same thing is
>>> true when mtu get reduced at master.
>>
>> The problem with this magic behavior is, well, that it's magic. There's
>> no way to tell what happens with a given slave when the master's MTU
>> gets changed just by looking at the current configuration. There's also
>> no way to switch the magic behavior back on once the slave's MTU is
>> changed.
>>
> I guess the logic would be as simple as - if mtu_adj for a slave is
> set to 0, then it's
> following master otherwise not. By setting different mtu for a slave, you will
> set this mtu_adj a positive number which would mean it's not following master.
> So it's subjected to clamping when masters' mtu is reducing but should stay
> otherwise. Also when slave decides to follow master again, it can set the mtu
> to be same as masters' (making mtu_adj == 0) and then it would start following
> master again.
>
> Whether it's magic or not, it's the current behavior and I know several use
> cases depend on this behavior which would be broken otherwise. The
> approach I proposed keeps that going for those who depend on that while
> adds an ability to set mtu per slave for the use case mentioned in this
> patch-set too.
>
Actually we can just have boolean val per slave indicating it's changed locally
instead of maintaining the mtu diff which is useless at this moment.

>> At minimum, you'd need some kind of indication that the slave's MTU is
>> following the master. And a way to toggle this back.
>>
>> Keefe's patch is much saner, the behavior is completely deterministic.
>>
>>  Jiri