linux-kernel - RE: [PATCH V2,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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Dec 2019 01:35:11 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Haiyang Zhang <haiyangz@...rosoft.com>,
        "sashal@...nel.org" <sashal@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Haiyang Zhang <haiyangz@...rosoft.com>,
        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 V2,net-next, 3/3] hv_netvsc: Name NICs based on vmbus
 offer sequence and use async probe

From: Haiyang Zhang <haiyangz@...rosoft.com> Sent: Monday, December 30, 2019 12:14 PM
> 
> The dev_num field in vmbus channel structure is assigned to the first

Let's use "VMBus" in text.

> available number when the channel is offered. So netvsc driver uses it
> for NIC naming based on channel offer sequence. Now re-enable the async
> probing mode for faster probing.
> 
> Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> ---
>  drivers/net/hyperv/netvsc_drv.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index f3f9eb8..39c412f 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -2267,10 +2267,14 @@ static int netvsc_probe(struct hv_device *dev,
>  	struct net_device_context *net_device_ctx;
>  	struct netvsc_device_info *device_info = NULL;
>  	struct netvsc_device *nvdev;
> +	char name[IFNAMSIZ];
>  	int ret = -ENOMEM;
> 
> -	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);
> +
>  	if (!net)
>  		goto no_net;
> 
> @@ -2355,6 +2359,14 @@ static int netvsc_probe(struct hv_device *dev,
>  		net->max_mtu = ETH_DATA_LEN;
> 
>  	ret = register_netdevice(net);
> +
> +	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);

The message above could be confusing.  "request another name" sounds
like a directive to the user/sysadmin, which I don't think it is.  Perhaps
better would be "requesting another name", which says the system is
handling the collision automatically.

Also will this second call to register_netdevice() actually assign a numeric
name?  If so, it would be really nice for the message to be output *after*
the second call to register_netdevice() and to show both the originally
selected name that collided as well as the new name.  We sometimes get
into NIC naming issues with customers in Azure, and when a new name
has to be selected it will help debugging if we can show both the original
selection and the new selection.  With both pieces of data, there's less
guessing about who did what regarding NIC naming.

Finally, having to choose a different name because of a collision does
*not* update the channel->dev_num value.  Subsequent calls to 
hv_set_devnum() will detect "in use" based on the originally assigned
dev_num value.  I don't think that fundamentally breaks anything, but
I wondered if you had thought about that case.   Maybe a comment here
to that effect would help a future reader of this code.

Michael

> +	}
> +
>  	if (ret != 0) {
>  		pr_err("Unable to register netdev.\n");
>  		goto register_failed;
> @@ -2496,7 +2508,7 @@ static int netvsc_resume(struct hv_device *dev)
>  	.suspend = netvsc_suspend,
>  	.resume = netvsc_resume,
>  	.driver = {
> -		.probe_type = PROBE_FORCE_SYNCHRONOUS,
> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>  	},
>  };
> 
> --
> 1.8.3.1