linux-kernel - Re: [PATCH] net: usbnet: allow overriding of default USB interface naming

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:   Mon, 14 Jun 2021 11:43:43 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jonathan Davies <jonathan.davies@...anix.com>
Cc:     Oliver Neukum <oneukum@...e.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew@...n.ch
Subject: Re: [PATCH] net: usbnet: allow overriding of default USB interface
 naming

On Mon, Jun 14, 2021 at 10:32:05AM +0100, Jonathan Davies wrote:
> On 12/06/2021 08:01, Greg KH wrote:
> > On Fri, Jun 11, 2021 at 03:23:39PM +0000, Jonathan Davies wrote:
> > > When the predictable device naming scheme for NICs is not in use, it is
> > > common for there to be udev rules to rename interfaces to names with
> > > prefix "eth".
> > > 
> > > Since the timing at which USB NICs are discovered is unpredictable, it
> > > can be interfere with udev's attempt to rename another interface to
> > > "eth0" if a freshly discovered USB interface is initially given the name
> > > "eth0".
> > > 
> > > Hence it is useful to be able to override the default name. A new usbnet
> > > module parameter allows this to be configured.
> > > 
> > > Signed-off-by: Jonathan Davies <jonathan.davies@...anix.com>
> > > Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@...anix.com>
> > > ---
> > >   drivers/net/usb/usbnet.c | 13 ++++++++++---
> > >   1 file changed, 10 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> > > index ecf6284..55f6230 100644
> > > --- a/drivers/net/usb/usbnet.c
> > > +++ b/drivers/net/usb/usbnet.c
> > > @@ -72,6 +72,13 @@ static int msg_level = -1;
> > >   module_param (msg_level, int, 0);
> > >   MODULE_PARM_DESC (msg_level, "Override default message level");
> > > +#define DEFAULT_ETH_DEV_NAME "eth%d"
> > > +
> > > +static char *eth_device_name = DEFAULT_ETH_DEV_NAME;
> > > +module_param(eth_device_name, charp, 0644);
> > > +MODULE_PARM_DESC(eth_device_name, "Device name pattern for Ethernet devices"
> > > +				  " (default: \"" DEFAULT_ETH_DEV_NAME "\")");
> > 
> > This is not the 1990's, please do not add new module parameters as they
> > are on a global driver level, and not on a device level.
> 
> The initial name is set at probe-time, so the device doesn't exist yet. So I
> felt like it was a choice between either changing the hard-coded "eth%d"
> string or providing a driver-level module parameter. Is there a better
> alternative?

This has always been this way, why is this suddenly an issue?  What
changed to cause the way we can name these devices after they have been
found like we have been for the past decade+?

> > Also changing the way usb network devices are named is up to userspace,
> > the kernel should not be involved in this.  What is wrong with just
> > renaming it in userspace as you want to today?
> 
> Yes, renaming devices is the responsibility of userspace. Normally udev will
> rename a device shortly after it is probed. But there's a window during
> which it has the name the kernel initially assigns. If there's other
> renaming activity happening during that window there's a chance of
> collisions.
> 
> Userspace solutions include:
>  1. udev backing off and retrying in the event of a collision; or
>  2. avoiding ever renaming a device to a name in the "eth%d" namespace.

Picking a different namespace does not cause a lack of collisions to
happen, you could have multiple usb network devices being found at the
same time, right?

So no matter what, 1) has to happen.

> Solution 1 is ugly and slow. It's much neater to avoid the collisions in the
> first place where possible.

This is not being solved by changing the name as you have to do this no
matter what.

And the code and logic in userspace is already there to do this, right?
This is not a new issue, what changed to cause it to show up for you?

> Solution 2 arises naturally from use of the predictable device naming
> scheme. But when userspace is not using that, solution 2 may not apply.

Again you always have to do 1 no matter what, so might as well just do
it.

> Yes, the problem is a result of userspace decisions, but that doesn't mean
> the kernel can't help make things easier.

Ideally, if you _can_ do something in userspace, you should, especially
for policy decisions like naming.  That is why udev was created 17 years
ago :)

thanks,

greg k-h