netdev - Re: [PATCH net] failover: eliminate callback hell

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:   Wed, 6 Jun 2018 14:24:47 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, kys@...rosoft.com,
        haiyangz@...rosoft.com, davem@...emloft.net,
        sridhar.samudrala@...el.com, netdev@...r.kernel.org,
        Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [PATCH net] failover: eliminate callback hell

On Wed, 6 Jun 2018 15:30:27 +0300
"Michael S. Tsirkin" <mst@...hat.com> wrote:

> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@...workplumber.org wrote:  
> > >The net failover should be a simple library, not a virtual
> > >object with function callbacks (see callback hell).  
> > 
> > Why just a library? It should do a common things. I think it should be a
> > virtual object. Looks like your patch again splits the common
> > functionality into multiple drivers. That is kind of backwards attitude.
> > I don't get it. We should rather focus on fixing the mess the
> > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> > model.  
> 
> So it seems that at least one benefit for netvsc would be better
> handling of renames.
> 
> Question is how can this change to 3-netdev happen?  Stephen is
> concerned about risk of breaking some userspace.
> 
> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> address, and you said then "why not use existing network namespaces
> rather than inventing a new abstraction". So how about it then? Do you
> want to find a way to use namespaces to hide the PV device for netvsc
> compatibility?
> 

Netvsc can't work with 3 dev model. MS has worked with enough distro's and
startups that all demand eth0 always be present. And VF may come and go.
After this history, there is a strong motivation not to change how kernel
behaves. Switching to 3 device model would be perceived as breaking
existing userspace.

With virtio you can  work it out with the distro's yourself.
There is no pre-existing semantics to deal with.

For the virtio, I don't see the need for IFF_HIDDEN.
With 3-dev model as long as you mark the PV and VF devices
as slaves, then userspace knows to leave them alone. Assuming userspace
is already able to deal with team and bond devices.
Any time you introduce new UAPI behavior something breaks.

On the rename front, I really don't care if VF can be renamed. And for
netvsc want to allow the PV device to be renamed. Udev developers want that
but have not found a stable/persistent value to expose to userspace
to allow it.