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: <7d1c3488-2d55-213f-b744-c71b665aa387@intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ