Bug 673675 - [PATCH] udev network device renaming 2-step exceeds IFNAMSIZ
Summary: [PATCH] udev network device renaming 2-step exceeds IFNAMSIZ
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 673676
TreeView+ depends on / blocked
 
Reported: 2011-01-29 15:27 UTC by Matt Domsch
Modified: 2011-02-03 07:50 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 673676 (view as bug list)
Environment:
Last Closed: 2011-02-03 07:50:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
udev-random_temporary_ifname.patch (829 bytes, patch)
2011-01-29 15:27 UTC, Matt Domsch
no flags Details | Diff

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:


Note You need to log in before you can comment on or make changes to this bug.