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: <20171220.134754.83098458334539703.davem@davemloft.net>
Date:   Wed, 20 Dec 2017 13:47:54 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     stephen@...workplumber.org
Cc:     netdev@...r.kernel.org, sthemmin@...rosoft.com
Subject: Re: [PATCH v2] hv_netvsc: automatically name slave VF network
 device

From: Stephen Hemminger <stephen@...workplumber.org>
Date: Tue, 19 Dec 2017 15:59:30 -0800

> Rename the VF device to ethX_vf based on the ethX as the
> synthetic device.  This eliminates the need for delay on setup,
> and the PCI (udev based) naming is not reproducible on Hyper-V
> anyway. The name of the VF does not matter since all control
> operations take place the primary device. It does make the
> user experience better to associate the names.
> 
> Based on feedback from all.systems.go talk.
> 
> Signed-off-by: Stephen Hemminger <sthemmin@...rosoft.com>
> ---
> v2 - also handle case where synthetic device gets renamed
>      and the case where rename causes clash with pre-existing device name

Besides Jakub's objections (which I agree with) it is just so
unexpected that changing the name of device X has the side effect of
changing the name of device Y.

This is why we do this policy stuff in userspace.  The kernel has no
business messing with these netdev names.

This patch means that if a user decides to add his own custom udev
rules for the VF (for whatever reason, it doesn't have to make sense
to you or me) we're just going to undo them.  That's bad.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ