Race condition for udev/persistent-net

Race condition for udev/persistent-net

[Matthias Schwarzott]

Hi there!

I am trying to find out why the persistent-net-rules only work sometimes for 
me (using udev-103-r3 on gentoo).

Steps to reproduce: (All files I use are relative to /etc/udev/rules.d)

1. Make sure 70-persistent-net.rules exists.
If not try reloading network modules
and running udevtrigger.

2. Modify NAME-Part of rules to something not used as default (either 
non "eth", or higher numbers like eth7 ...)

3. udevcontol reload_rules


After these steps one can try wheather the existing rules now get applied 
every time or not by:

4. rmmod and modprobe network module.

5. Verify name by "ifconfig -a|grep Ethernet"

6. If name is wrong executing udevtrigger and recheck.

For me the name was correct in 3 out of 15 tries.


The generated rules look like this for me (after changing NAME):
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM="net", DRIVERS="?*", ATTRS{address}="xx:xx:xx:xx:xx:xx", 
NAME="eth8"

It seems that DRIVERS is not always set when trying this rule. Removing it, or 
adding next rule to 05-udev-early.rules helped:
ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="device/driver"


But the problem with this rule is: udev now waits also for a driver entry for 
loopback/bridge devices. This gives ugly log/console output.

Is there a better place to put such a wait-rule?



It is also possible to just skip the DRIVERS="?*" part from the generated 
rules and only keep it in the generator (with the wait inside the generating 
part) to set a reasonable comment.


Greetings
Matthias Schwarzott

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Race condition for udev/persistent-net

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]

Matthias Schwarzott wrote:
> It is also possible to just skip the DRIVERS=="?*" part from the
> generated rules and only keep it in the generator (with the wait
> inside the generating part) to set a reasonable comment.

Unfortunately no; from /lib/udev/write_net_rules:

# the DRIVERS key is needed to not match bridges and VLAN sub-interfaces
match="DRIVERS==\"?*\", ATTRS{address}==\"$MAC_ADDR\""

If DRIVERS is not present, then if you set up VLAN devices that are
supposed to be named e.g. eth0.1 and eth0.2 (because you've used vconfig
to set this naming policy), then this rule would match them when they
get created.  So they'd be named plain eth0 -- or more likely one would
be named eth0_retry and the other would log an error, because eth0 is in
use -- because their MAC address is the same as eth0's MAC, and the rule
matches.

What kernel version is this?  It almost sounds like your kernel has
issues with uevent ordering (the time the uevent is sent versus the time
various attributes are created).  I haven't tried your test under
2.6.19.2, but I will later today.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Race condition for udev/persistent-net

[Matthias Schwarzott]

On Thursday 18 January 2007 11:31, Matthias Schwarzott wrote:
>
> It seems that DRIVERS is not always set when trying this rule. Removing it,
> or adding next rule to 05-udev-early.rules helped:
> ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="device/driver"
>
>
> But the problem with this rule is: udev now waits also for a driver entry
> for loopback/bridge devices. This gives ugly log/console output.
>
> Is there a better place to put such a wait-rule?
>
Inbetween we found an even better rule to force udev waiting for device/driver 
entry to appear:
ACTION="add", SUBSYSTEM="net", ENV{PHYSDEVDRIVER}="?*", 
WAIT_FOR_SYSFS="device/driver"

Perhaps something like this should be added to rules contained in 
udev-tarball, or at least meantioned in documentation.

Greetings
  Matthias Schwarzott

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Race condition for udev/persistent-net

[Kay Sievers]

On 1/24/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> On Thursday 18 January 2007 11:31, Matthias Schwarzott wrote:
> >
> > It seems that DRIVERS is not always set when trying this rule. Removing it,
> > or adding next rule to 05-udev-early.rules helped:
> > ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="device/driver"
> >
> > But the problem with this rule is: udev now waits also for a driver entry
> > for loopback/bridge devices. This gives ugly log/console output.
> >
> > Is there a better place to put such a wait-rule?
> >
> Inbetween we found an even better rule to force udev waiting for device/driver
> entry to appear:
> ACTION="add", SUBSYSTEM="net", ENV{PHYSDEVDRIVER}="?*",
> WAIT_FOR_SYSFS="device/driver"

All PHYS* values are deprecated and will go away. It's a property of a
parent device copied into a child device, which is wrong to do,  as it
will break if future changes require to insert something between these
devices.

Kay

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel