[PATCH] net: usbnet: allow overriding of default USB interface naming

[PATCH] net: usbnet: allow overriding of default USB interface naming

[Jonathan Davies]

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@nutanix.com>
Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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 "\")");
+
 /*-------------------------------------------------------------------------*/
 
 /* handles CDC Ethernet and many other network "bulk data" interfaces */
@@ -1730,12 +1737,12 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
 			goto out1;
 
 		// heuristic:  "usb%d" for links we know are two-host,
-		// else "eth%d" when there's reasonable doubt.  userspace
-		// can rename the link if it knows better.
+		// else eth_device_name when there's reasonable doubt.
+		// userspace can rename the link if it knows better.
 		if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
 		    ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
 		     (net->dev_addr [0] & 0x02) == 0))
-			strcpy (net->name, "eth%d");
+			strscpy(net->name, eth_device_name, sizeof(net->name));
 		/* WLAN devices should always be named "wlan%d" */
 		if ((dev->driver_info->flags & FLAG_WLAN) != 0)
 			strcpy(net->name, "wlan%d");
-- 
2.9.3

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

[Andrew Lunn]

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@nutanix.com>
> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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 "\")");

Module parameter are not liked in the network stack.

It actually seems like a udev problem, and you need to solve it
there. It is also not specific to USB. Any sort of interface can pop
up at an time, especially with parallel probing of busses. So you need
udev to detect there has been a race condition and try again with the
rename.

     Andrew

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

[Jonathan Davies]

On 11/06/2021 18:16, Andrew Lunn 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@nutanix.com>
>> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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 "\")");
> 
> Module parameter are not liked in the network stack.

Thanks, I wasn't aware. Please help me understand: is that in an effort 
to avoid configurability altogether, or because there's some preferred 
mechanism for performing configuration?

> It actually seems like a udev problem, and you need to solve it
> there. It is also not specific to USB. Any sort of interface can pop
> up at an time, especially with parallel probing of busses.

Yes, this is also applicable to the naming done for all ethernet 
devices. But I've seen the problem multiple times for USB NICs, which is 
why I proposed a fix here first.

> So you need
> udev to detect there has been a race condition and try again with the
> rename.

(See reply to similar question in sibling thread.)

Thanks,
Jonathan

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

[Oliver Neukum]

Am Montag, den 14.06.2021, 10:32 +0100 schrieb Jonathan Davies:
> On 11/06/2021 18:16, Andrew Lunn wrote:
> > On Fri, Jun 11, 2021 at 03:23:39PM +0000, Jonathan Davies wrote:

Hi,

> > > Hence it is useful to be able to override the default name. A new
> > > usbnet
> > > module parameter allows this to be configured.

1. This issue exists with all hotpluggable interfaces
2. It exists for all USB devices so it does not belong in usbnet,
leaving out drivers like kaweth.

> > > 
> > Module parameter are not liked in the network stack.
> 
> Thanks, I wasn't aware. Please help me understand: is that in an
> effort 
> to avoid configurability altogether, or because there's some
> preferred 
> mechanism for performing configuration?

Configurability belongs into user space if possible.
> 
> > It actually seems like a udev problem, and you need to solve it
> > there. It is also not specific to USB. Any sort of interface can
> > pop
> > up at an time, especially with parallel probing of busses.
> 
> Yes, this is also applicable to the naming done for all ethernet 
> devices. But I've seen the problem multiple times for USB NICs, which
> is 
> why I proposed a fix here first.

Because USb devices are common. Your observations are determined
by ubiquity, not intrinsic factors.

> > So you need
> > udev to detect there has been a race condition and try again with
> > the
> > rename.
> 

Yes, now, it may be that we do not export the information udev
would need to or you want new kinds of rules. But I see no evidence
of that.

	Regards
		Oliver

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

[Greg KH]

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@nutanix.com>
> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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.

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?

thanks,

greg k-h

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

[Jonathan Davies]

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@nutanix.com>
>> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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?

> 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.

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

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

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

Thanks,
Jonathan

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

[Greg KH]

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@nutanix.com>
> > > Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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

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

[Jonathan Davies]

On 14/06/2021 10:43, Greg KH wrote:
> 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@nutanix.com>
>>>> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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+?

The thing that changed for me was that system-udevd does *not* have the 
backoff and retry logic that traditional versions of udev had.

Compare implementations of rename_netif in 
https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/src/udev-event.c 
(traditional udev, which handles collisions) and 
https://github.com/systemd/systemd/blob/main/src/udev/udev-event.c 
(systemd-udevd, which does not handle collisions).

I think this logic was removed under the assumption that users of 
systemd-udevd would also use the predictable device naming scheme, 
meaning renames are guaranteed to not collide with devices being probed.

>>> 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.

Within a namespace, the "%d" in "eth%d" means __dev_alloc_name finds a 
name that's not taken. I didn't check the locking but assume that can 
only happen serially, in which case two devices probed in parallel would 
not mutually collide.

So I don't think it's necessarily true that 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?

As above, the logic's not there if userspace is using systemd-udevd.

>> 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 :)

I'm arguing that a bit of flexibility in the kernel can avoid an 
undesirable workaround in userspace. But I can respect the principle you 
describe.

Thanks,
Jonathan

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

[Andrew Lunn]

> > > 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.
> 
> Within a namespace, the "%d" in "eth%d" means __dev_alloc_name finds a name
> that's not taken. I didn't check the locking but assume that can only happen
> serially, in which case two devices probed in parallel would not mutually
> collide.
> 
> So I don't think it's necessarily true that 1) has to happen.

Say you changed the namespace to usb%d. And you want the device in USB
port 1.4 to be usb1 and the device in USB port 1.3 to be usb0. They
probe the other way around. You have the same problem, you need to
handle the race condition in udev, back off an try again.

As GregKH said, 1) has to happen.

   Andrew

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

[Jonathan Davies]

On 14/06/2021 13:23, Andrew Lunn wrote:
>>>> 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.
>>
>> Within a namespace, the "%d" in "eth%d" means __dev_alloc_name finds a name
>> that's not taken. I didn't check the locking but assume that can only happen
>> serially, in which case two devices probed in parallel would not mutually
>> collide.
>>
>> So I don't think it's necessarily true that 1) has to happen.
> 
> Say you changed the namespace to usb%d. And you want the device in USB
> port 1.4 to be usb1 and the device in USB port 1.3 to be usb0. They
> probe the other way around. You have the same problem, you need to
> handle the race condition in udev, back off an try again.

The point of the patch was that if your intended names are usb0 and usb1 
then the module parameter would allow you to nominate a prefix for the 
initial names that's not "usb", thereby avoiding collisions.

But I can see that the consensus is to live with the possibility of 
overlap between the names initially assigned by the kernel and the 
intended names, so this is moot.

Thanks for all the input.

Jonathan

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

[Greg KH]

On Mon, Jun 14, 2021 at 11:58:57AM +0100, Jonathan Davies wrote:
> On 14/06/2021 10:43, Greg KH wrote:
> > 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@nutanix.com>
> > > > > Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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+?
> 
> The thing that changed for me was that system-udevd does *not* have the
> backoff and retry logic that traditional versions of udev had.
> 
> Compare implementations of rename_netif in
> https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/src/udev-event.c
> (traditional udev, which handles collisions) and
> https://github.com/systemd/systemd/blob/main/src/udev/udev-event.c
> (systemd-udevd, which does not handle collisions).

Then submit a change to add the logic back.  This looks like a userspace
tool breaking existing setups, so please take it up with the developers
of that tool.  The kernel has not changed or "broken" anything here.

> I think this logic was removed under the assumption that users of
> systemd-udevd would also use the predictable device naming scheme, meaning
> renames are guaranteed to not collide with devices being probed.

Why are you not using the predictable device naming scheme?  If you have
multiple network devices in the system, it seems like that is a good
idea to follow as the developers added that for a reason.

> > > > 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.
> 
> Within a namespace, the "%d" in "eth%d" means __dev_alloc_name finds a name
> that's not taken. I didn't check the locking but assume that can only happen
> serially, in which case two devices probed in parallel would not mutually
> collide.
> 
> So I don't think it's necessarily true that 1) has to happen.

Multiple USB devices in the system will cause the same exact thing to
happen with your patch, so you still need 1).

thanks

greg k-h

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

[Jonathan Davies]

On 14/06/2021 14:51, Greg KH wrote:
> On Mon, Jun 14, 2021 at 11:58:57AM +0100, Jonathan Davies wrote:
>> On 14/06/2021 10:43, Greg KH wrote:
>>> 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@nutanix.com>
>>>>>> Suggested-by: Prashanth Sreenivasa <prashanth.sreenivasa@nutanix.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+?
>>
>> The thing that changed for me was that system-udevd does *not* have the
>> backoff and retry logic that traditional versions of udev had.
>>
>> Compare implementations of rename_netif in
>> https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/src/udev-event.c 
>> (traditional udev, which handles collisions) and
>> https://github.com/systemd/systemd/blob/main/src/udev/udev-event.c 
>> (systemd-udevd, which does not handle collisions).
> 
> Then submit a change to add the logic back.  This looks like a userspace
> tool breaking existing setups, so please take it up with the developers
> of that tool.  The kernel has not changed or "broken" anything here.

(I didn't mean to imply that the kernel was to blame, merely that a 
kernel change could help make things tidier.)

>> I think this logic was removed under the assumption that users of
>> systemd-udevd would also use the predictable device naming scheme, meaning
>> renames are guaranteed to not collide with devices being probed.
> 
> Why are you not using the predictable device naming scheme?  If you have
> multiple network devices in the system, it seems like that is a good
> idea to follow as the developers added that for a reason.

Sadly in my case this isn't possible for reasons beyond my control. I'd 
like to move things in that direction but in the meantime thought this 
workaround could have been helpful for others who find themselves in the 
same position as me.

Thanks for all the input.

Jonathan

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

[Jakub Kicinski]

On Mon, 14 Jun 2021 15:53:53 +0100 Jonathan Davies wrote:
> >> Compare implementations of rename_netif in
> >> https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/src/udev-event.c 
> >> (traditional udev, which handles collisions) and
> >> https://github.com/systemd/systemd/blob/main/src/udev/udev-event.c 
> >> (systemd-udevd, which does not handle collisions).  

That explains some user reports I've been seeing :o

> > Then submit a change to add the logic back.  This looks like a userspace
> > tool breaking existing setups, so please take it up with the developers
> > of that tool.  The kernel has not changed or "broken" anything here.  
> 
> (I didn't mean to imply that the kernel was to blame, merely that a 
> kernel change could help make things tidier.)

If you're attempting to fix this in systemd please share the PR info
so we can voice support!