Hide Forgot
+++ This bug was initially created as a clone of Bug #673675 +++ Created attachment 475950 [details] udev-random_temporary_ifname.patch Description of problem: From linux-hotplug-owner.org Sun Nov 28 21:29:12 2010 Date: Sun, 28 Nov 2010 21:29:09 -0600 From: Matt Domsch <Matt_Domsch> To: linux-hotplug.org Subject: net device renaming 2-step, IFNAMSIZ limit Once again, IFNAMSIZ bites me. I see this in the udev debug logs when using biosdevname (which I finally got working with SR-IOV devices tonight): renamed network interface eth60 to eth60-pci2#0_60 renamed network interface eth60-pci2#0_60 to pci2#0_60 So, it worked, however, note that the rename happens in 2 steps, the middle step of which uses a name that's dangerously close to IFNAMSIZ, in fact it is 15 chars there. In my testing, I'm doing: modprobe ixgbe max_vfs=63 which generates ethN..(N+127) interfaces (yes, 128 new interfaces) on this dual-port card. Combine that with the longer names that biosdevname is suggesting: pciNN#PP_VVV which is itself already 12 chars if all the fields are used to their maximum length, and the concatenation of <oldname>-<newname> is way past IFNAMSIZ. I need a solution in which the intermediate name doesn't exceed 15 characters, and is guaranteed to be unique, as there may be lots of udev instances running in parallel trying to do the same thing. Ideas? (note, vconfig can create VLANs for interfaces, which needs another 5 characters appended on the end, but that's for another day). Thanks,From linux-hotplug-owner.org Mon Dec 6 21:02:52 2010 Date: Tue, 07 Dec 2010 00:45:04 -0200 From: Piter PUNK <piterpunk> To: Matt Domsch <Matt_Domsch> CC: linux-hotplug.org Subject: Re: net device renaming 2-step, IFNAMSIZ limit Matt Domsch wrote: >I see this in the udev debug logs when using biosdevname (which I >finally got working with SR-IOV devices tonight): > >renamed network interface eth60 to eth60-pci2#0_60 >renamed network interface eth60-pci2#0_60 to pci2#0_60 > >So, it worked, however, note that the rename happens in 2 steps, the >middle step of which uses a name that's dangerously close to >IFNAMSIZ, in fact it is 15 chars there. > ><...> > >I need a solution in which the intermediate name doesn't exceed 15 >characters, and is guaranteed to be unique, as there may be lots of >udev instances running in parallel trying to do the same thing. > >Ideas? As we talk on #udev, there is a patch that uses hash32 function inside libudev to create the intermediate name. We use the "oldname-newname" to create the hash. With that, exceeding IFNAMSIZ isn't a problem:From linux-hotplug-owner.org Mon Dec 6 21:54:13 2010 Date: Mon, 6 Dec 2010 21:54:10 -0600 From: Matt Domsch <Matt_Domsch> To: Piter PUNK <piterpunk> Cc: linux-hotplug.org Subject: Re: net device renaming 2-step, IFNAMSIZ limit On Tue, Dec 07, 2010 at 12:45:04AM -0200, Piter PUNK wrote: > As we talk on #udev, there is a patch that uses hash32 function inside > libudev to create > the intermediate name. We use the "oldname-newname" to create the hash. > With that, > exceeding IFNAMSIZ isn't a problem: Thanks piterpunk. I built udev on a Fedora 14 box, with this patch, and it works. However, I don't see udev doing the 2-step anymore, perhaps that was just a figment of the loglevel. Anyhow, it looks right, and doesn't blow up. Thanks, Matt Matt Additional info:
If biosdevname generates unique names, then a two step renaming should not be needed in any case!
AFAIK, biosdevname always generates unique names. It has code that, should it detect that it _would_ generate non-unique names, it does not return _any_ names. I'll respond to the thread on linux-hotplug.