Message-ID: <Z01uqI7hUNyCGFcw@atmark-techno.com>
Date: Mon, 2 Dec 2024 17:24:08 +0900
From: Dominique MARTINET <dominique.martinet@...ark-techno.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Oliver Neukum <oneukum@...e.com>, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org,
	Greg Thelen <gthelen@...gle.com>,
	John Sperbeck <jsperbeck@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH net] net: usb: usbnet: fix name regression

Greg Kroah-Hartman wrote on Mon, Dec 02, 2024 at 07:29:52AM +0100:
> On Mon, Dec 02, 2024 at 12:50:15PM +0900, Dominique MARTINET wrote:
> > So we hit the exact inverse problem with this patch: our device ships an
> > LTE modem which exposes a cdc-ethernet interface that had always been
> > named usb0, and with this patch it started being named eth1, breaking
> > too many hardcoded things expecting the name to be usb0 and making our
> > devices unable to connect to the internet after updating the kernel.
> > 
> > 
> > Long term we'll probably add an udev rule or something to make the name
> > explicit in userspace and not risk this happening again, but perhaps
> > there's a better way to keep the old behavior?
> > 
> > (In particular this hit all stable kernels last month so I'm sure we
> > won't be the only ones getting annoyed with this... Perhaps reverting
> > both patches for stable branches might make sense if no better way
> > forward is found -- I've added stable@ in cc for heads up/opinions)
> 
> Device names have NEVER been stable.  They move around and can change on
> every boot, let alone almost always changing between kernel versions.
> That's why we created udev, to solve this issue.

Yes, I agree and we will add an udev rule to enforce the name for later
updates (I really am just a messenger here as "the kernel guy", after
having been asked why did this change), and I have no problem with this
behavior changing on master whatever the direction this takes
(... assuming the check was written as intended)

Now you're saying this I guess the main reason we were affected is that
alpine never made the "stable network interface name" systemd-udev
switch, so for most people that interface will just be named
enx028072781510 anyway and most people will probably not notice this...
(But then again these don't use the "new" name either, so they just
don't care)


With that said, and while I agree the names can change, I still think
there's some hierarchy here -- the X part of ethX/usbX can change on
every boot and I have zero problem with that, but I wouldn't expect the
"type" part to change so easily, and I would have assume stable kernels
would want to at least try to preserve these unless there is a good
reason not to.
The two commits here (8a7d12d674ac ("net: usb: usbnet: fix name
regression") and bab8eb0dd4cb ("usbnet: modern method to get random
MAC") before it) are just cleanup I see no problem reverting them for
stable kernels if they cause any sort of issue, regardless of how
userspace "should" work.


> But how is changing the MAC address changing the device naming here?
> How are they linked to suddenly causing the names to switch around?

That's also something I'd like to understand :)

Apparently, usbnet had a rule that said that if a device is ethernet,
and either (it's not point-to-point) or (mac[0] & 0x2 == 0) then we
would rename it to ethX instad of the usbX name.

commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") made it so
the last part of the check would rename it to ethX if the mac has been
set by any driver, so my understanding is that all drivers that used to
set the mac to something that avoided the 0x2 would now get renamed?...
But as you can see above from the stable device name I gave, the mac
address does start with 02, so I don't understand why it hadn't been
renamed before or what this rules mean and why it's here...?

The commit message mentions commit bab8eb0dd4cb ("usbnet: modern method
to get random MAC") which changed the timing usbnet would set a random
mac, but in my case the mac does come from the hardware (it's stable
across reboots), so I guess I wasn't affected by that commit but the new
one trying to make it better for people with a random mac made it worse
for my case?


Anyway, as said above we'll try to figure something for udev, and this
will hopefully be a heads up for anyone else falling here doing a web
search.
(Our users are rather adverse to changes so I don't see myself enabling
static interface names anytime soon, but time will tell how that turns
out...)

Cheers,
-- 
Dominique

Powered by blists - more mailing lists