This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 673676

Summary: [PATCH] udev network device renaming 2-step exceeds IFNAMSIZ
Product: Red Hat Enterprise Linux 6 Reporter: Matt Domsch <matt_domsch>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0CC: harald, john_hull, jonathan, jordan_hargrave, linux-bugs, narendra_k, shyam_iyer
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 673675 Environment:
Last Closed: 2011-02-11 16:54:39 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 673675    
Bug Blocks: 501533    

Description Matt Domsch 2011-01-29 10:28:29 EST
+++ 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@vger.kernel.org  Sun Nov 28 21:29:12 2010
Date:   Sun, 28 Nov 2010 21:29:09 -0600
From: Matt Domsch <Matt_Domsch@dell.com>
To: linux-hotplug@vger.kernel.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@vger.kernel.org  Mon Dec  6 21:02:52 2010
Date:   Tue, 07 Dec 2010 00:45:04 -0200
From: Piter PUNK <piterpunk@unitednerds.org>
To: Matt Domsch <Matt_Domsch@dell.com>
CC: linux-hotplug@vger.kernel.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@vger.kernel.org  Mon Dec  6 21:54:13 2010
Date:   Mon, 6 Dec 2010 21:54:10 -0600
From: Matt Domsch <Matt_Domsch@dell.com>
To: Piter PUNK <piterpunk@unitednerds.org>
Cc: linux-hotplug@vger.kernel.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:
Comment 2 Harald Hoyer 2011-02-09 09:19:38 EST
If biosdevname generates unique names, then a two step renaming should not be needed in any case!
Comment 3 Matt Domsch 2011-02-09 09:50:04 EST
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.