netdev - Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

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: <4cd67675-b4d5-aca7-9df4-f5fc6bfa4c99@oracle.com>
Date:   Tue, 26 Feb 2019 16:49:06 -0800
From:   si-wei liu <si-wei.liu@...cle.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        Siwei Liu <loseweigh@...il.com>, Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        virtio-dev <virtio-dev@...ts.oasis-open.org>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Jakub Kicinski <kubakici@...pl>,
        Jason Wang <jasowang@...hat.com>, liran.alon@...cle.com
Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC
 PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use
 the bypass framework)



On 2/25/2019 6:05 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2019 at 05:39:12PM -0800, Stephen Hemminger wrote:
>>>>>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
>>>>>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
>>>>>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
>>>>>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
>>>>> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
>>>>> model as much transparent to a real NIC as possible, while a hidden netns is
>>>>> just the vehicle). However, I recall there was resistance around this
>>>>> discussion that even the concept of hiding itself is a taboo for Linux
>>>>> netdev. I would like to summon potential alternatives before concluding
>>>>> 1-netdev is the only solution too soon.
>>>>>
>>>>> Thanks,
>>>>> -Siwei
>>>> Your scripts would not work at all then, right?
>>> At this point we don't claim images with such usage as SR-IOV live
>>> migrate-able. We would flag it as live migrate-able until this ethtool
>>> config issue is fully addressed and a transparent live migration
>>> solution emerges in upstream eventually.
>> The hyper-v netvsc with 1-dev model uses a timeout to allow  udev to do its rename.
>> I proposed a patch to key state change off of the udev rename, but that patch was
>> rejected.
> Of course that would mean nothing works without udev - was
> that the objection? Could you help me find that discussion pls?
Yeah, the kernel should work with and without udev rename - typically 
the kernel is agnostic of upcoming rename. User may opt out for kernel 
provided names (particularly on older distros) then no rename would ever 
happen.

I ever thought about this approach but didn't think it would fit. But, 
what is the historical reason that prevents slave from being renamed 
after being opened? Could we specialize a code path for this kernel 
created device, as net_failover shouldn't carry over any history burden?


Thanks,
-Siwei