netdev - Re: [PATCH net v6] failover: allow name change on IFF

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]

Date:   Sat, 6 Apr 2019 19:45:02 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     si-wei liu <si-wei.liu@...cle.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     davem@...emloft.net, kubakici@...pl, alexander.duyck@...il.com,
        jiri@...nulli.us, netdev@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, liran.alon@...cle.com,
        boris.ostrovsky@...cle.com, vijay.balakrishna@...cle.com
Subject: Re: [PATCH net v6] failover: allow name change on IFF_UP slave
 interfaces


On 4/6/2019 12:21 AM, si-wei liu wrote:

>>>
>>> Stephen are you happy with this approach?
>> I think it is the best solution for what you want to do.
> 
> Since you're asking specifically, I tried what you suggested below.
> 
>> Did you test with some things like Free Range Routing,
> 
> Although there might be spurious warning (which is a check for sanity 
> more than an error) while slave interface is up, slave rename had been 
> handled quite well there, no matter which state slave is at.
> 
> https://github.com/FRRouting/frr/blob/master/zebra/if_netlink.c#L97
> 
> The FRR users are supposed to operate on failover master interface 
> anyway. No one is expected to configure those passive interfaces for 
> routing.
> 
>> VPP
> Nothing particular was seen for this one. The netlink usage there 
> doesn't seem related to my change:
> https://github.com/FDio/vpp/blob/master/src/vnet/devices/netlink.c
> 
>> or other userspace
>> control planes that consume netlink?
> dhcpcd (https://github.com/kobolabs/dhcpcd/blob/kobo/if-linux.c#L761) 
> was tested OK.
> 
> In addition, the patch seems to play quite well with systemd-udev and 
> dracut/initramfs-tools. No breakage, no weird error message was seen.
> 
> What else do you suggest we should try/test with?

Thanks Siwei for all the tests you are trying out. Did you notice that 
any of these tests required the NETDEV_CHANGE notifier that you added?

-Sridhar