linux-kernel - RE: [PATCH V3,net-next, 0/3] Add vmbus dev

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] [day] [month] [year] [list]

Date:   Fri, 3 Jan 2020 02:41:12 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     David Miller <davem@...emloft.net>
CC:     "sashal@...nel.org" <sashal@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "olaf@...fle.de" <olaf@...fle.de>, vkuznets <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc probe
 options

> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Thursday, January 2, 2020 7:30 PM
> To: Haiyang Zhang <haiyangz@...rosoft.com>
> Cc: sashal@...nel.org; linux-hyperv@...r.kernel.org; netdev@...r.kernel.org;
> KY Srinivasan <kys@...rosoft.com>; Stephen Hemminger
> <sthemmin@...rosoft.com>; olaf@...fle.de; vkuznets
> <vkuznets@...hat.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc
> probe options
> 
> From: Haiyang Zhang <haiyangz@...rosoft.com>
> Date: Tue, 31 Dec 2019 14:13:31 -0800
> 
> > Add dev_num for vmbus device based on channel offer sequence.
> > User programs can use this number for nic naming.
> > Async probing option is allowed for netvsc. Sync probing is still the
> > default.
> 
> I don't like this at all, sorry.
> 
> If 4 devices get channels we will have IDs 1, 2, 3, 4.
> 
> Then if channel 3 is taken down, the next one will get 3 which is not in order
> any more.
> 
> It is not even clear what semantics these numbers have in any particular
> sequence or probe situation.
> 
> You have to use something more persistent across boots to number and strictly
> identify these virtual devices.
> 
> I'm not applying this.

The idea of this patch set is to make the naming of async probing same as that
in sync probing.

So, the semantics of this dev_num is actually same as the default "eth%d" naming --
	"Find the smallest number >=0, which is not in use."

In cases:
1) There is no hot add/remove devices in current boot, this scheme does provide 
persistent dev_num across reboot, because Hyper-V hosts offer the primary channels
in order. So the results based on this number with async probing will be the same 
as existing Sync probing.

2) If there is hot add/remove devices, this scheme generates the same results (when
user program use dev_num)  as the default naming mode -- by using the smallest
available number N in the format ethN.

In case of hot add/remove of virtual NICs, the removed NIC are gone, and the newly 
added NIC is a completely new virtual device with new device instance UUID. So if we 
don't reuse the previous numbers, the device name ethN will grow unbounded. For 
example, hot add/remove a virtual NIC 100 times, you will have a name like eth100. This 
not what the default naming scheme does, and we are not doing it for dev_num here 
either.

So the semantics is: "Find smallest number >=0, and not in use".

But if any customer wants to have a 1:1 mapping between the UUID and device name, they
can still implement that in user mode... And that's why this patch set doesn't change
the kernel naming from driver -- it just provides a new variable, "dev_num", so user 
mode program has the option to use it in async mode with knowledge of the channel
offer sequence.

Thanks,
- Haiyang