Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ 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:
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.