netdev - RE: [PATCH net-next, 3/3] hv_netvsc: Name NICs based on vmbus offer sequence and use async probe

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]

Message-ID: <MN2PR21MB13754551735F3F2A3639D269CA240@MN2PR21MB1375.namprd21.prod.outlook.com>
Date:   Sun, 29 Dec 2019 01:23:39 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
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>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next, 3/3] hv_netvsc: Name NICs based on vmbus offer
 sequence and use async probe



> -----Original Message-----
> From: Stephen Hemminger <stephen@...workplumber.org>
> Sent: Saturday, December 28, 2019 7:13 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>; davem@...emloft.net; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH net-next, 3/3] hv_netvsc: Name NICs based on vmbus offer
> sequence and use async probe
> 
> On Sat, 28 Dec 2019 15:46:33 -0800
> Haiyang Zhang <haiyangz@...rosoft.com> wrote:
> 
> > -	net = alloc_etherdev_mq(sizeof(struct net_device_context),
> > -				VRSS_CHANNEL_MAX);
> > +	snprintf(name, IFNAMSIZ, "eth%d", dev->channel->dev_num);
> > +	net = alloc_netdev_mqs(sizeof(struct net_device_context), name,
> > +			       NET_NAME_ENUM, ether_setup,
> > +			       VRSS_CHANNEL_MAX, VRSS_CHANNEL_MAX);
> > +
> 
> Naming is a hard problem, and best left to userspace.
> By choosing ethN as a naming policy, you potentially run into naming
> conflicts with other non netvsc devices like those passed through or
> SR-IOV devices.
If the dev_num based naming conflicts with existing device, it will fall back to 
the previous scheme: "choose the next available eth* name by specifying eth%d".
See the fall back code path below:
        if (ret == -EEXIST) {
                pr_info("NIC name %s exists, request another name.\n",
                        net->name);
                strlcpy(net->name, "eth%d", IFNAMSIZ);
                ret = register_netdevice(net);
        }


> Better to have udev use dev_num and use something like envN or something.
> Udev also handles SRIOV devices in later versions.
> 
> Fighting against systemd, netplan, etc is not going to be make friends.

When netvsc was initially created, it uses "seth*" naming. But with strong requests 
from many customers, we switched back to the regular "eth*" naming format.

The results of using dev_num based "eth*" names is same as what we are doing now --
The existing synchronous probing already generates "eth*" based on channel offer
sequence. With my patch, it still generates the same naming, but with asynchronous
probing.

So all the udev, or other user daemons, sees the same name for each device as before. 
And, they can still set these names like what they do today.

Thanks,
- Haiyang