Re: udev, PROGRAM and races...

[Andrey Borzenkov <arvidjaar@mail.ru>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> This is done with rule like:
>
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_CDROM}=="?*", \
> PROGRAM="/lib/udev/udev_cdrom_helper", SYMLINK+="%c"
>
> This helper tries to get the next free %d index to create cdrom%d, for
> example.
> The problem is that the launch of both helpers for hda and add seems to be
> done in parallel and the helper gets racy, so both cdroms get id 0, and the
> last that comes owns it:
>
> helper instance for hda        helper instance for hdd
> Does cdrom0 exist ? No
>                                Does cdrom0 exist ? No
> ln -sf hda cdrom0
>                                ln -sf hdd cdrom0
>
> ????
>

Do you have real example of race condition?

> Is there any way to serialize the calls to 'PROGRAM'. I tried something
> like:
>
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_CDROM}=="?*",
> PROGRAM="/usr/bin/flock /sys/block /lib/udev/udev_cdrom_helper",
> SYMLINK+="%c"
>
> But looks a lot ugly.
>

Why? It is probably the simplest fix actually (assuming sysfs does support 
locking, I am not sure).

> Any standard way to do this ?

I never liked this automatic creation of symlinks, I believe this has to be 
done as part of device configuration (harddrake on distro you likely mean :)

> Can I still use %e, or is it really really deprecated ? this was easy:
>
> ENV{ID_CDROM_CD_RW}=="?*",  SYMLINK+="burner%e", MODE="0666",
> GROUP="cdwriter" ENV{ID_CDROM_DVD_R}=="?*",  SYMLINK+="burner%e",
> MODE="0666", GROUP="cdwriter"

Yes it is deprecated exactly for the same reason. What ensures uniqueness of 
%e?

regards

- -andrey

PS I believe it is more appropriate for distro-specific list actually.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFENBYWR6LMutpd94wRAk4qAJoDaSaLY4nDCgif0ybFdumc2Q7NzACgvo1n
U6fB7VUhQ70FG4nql8a6Nwk=
=fnir
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/