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,