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: <20180112093413.683560bf@redhat.com>
Date:   Fri, 12 Jan 2018 09:34:13 +0100
From:   Jiri Benc <jbenc@...hat.com>
To:     "Mahesh Bandewar (महेश बंडेवार)" <maheshb@...gle.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, 11 Jan 2018 08:59:58 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> 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.

How can the mtu_adj value be queried and set from user space?

> 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.

I don't think this works currently. When someone (does not have to be
you, it can be a management software running in background) sets the
MTU to the current value, the magic behavior is lost without any way to
restore it (unless I'm missing a way to restore it, see my question
above). So any user that depends on the magic behavior is broken anyway
even now.

 Jiri