netdev - Re: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc probe options

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:   Thu, 02 Jan 2020 16:29:41 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     haiyangz@...rosoft.com
Cc:     sashal@...nel.org, linux-hyperv@...r.kernel.org,
        netdev@...r.kernel.org, kys@...rosoft.com, sthemmin@...rosoft.com,
        olaf@...fle.de, 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.