Bug 673675

Summary: [PATCH] udev network device renaming 2-step exceeds IFNAMSIZ
Product: [Fedora] Fedora Reporter: Matt Domsch <matt_domsch>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: harald, john_hull, jonathan, jordan_hargrave, linux-bugs, narendra_k, shyam_iyer
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 673676 (view as bug list) Environment:
Last Closed: 2011-02-03 07:50:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 673676    
Attachments:
Description Flags
udev-random_temporary_ifname.patch none

Description Matt Domsch 2011-01-29 15:27:27 UTC
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: