Milan Broz schrieb:
On 03/25/2010 04:56 PM, Ali Reza Sajedi wrote:
For this purpose I have a perl script called via a dev-rule when the drive
is attached.
If it is cryptsetup 1.0.6 it internally calls udevadm settle, you
are running from udev rule, so it waits for itself ->deadlock -> timeout.
That is indeed true, since calling udevadm was a really bad hack, it
does wait for complete settlement, which of course yields a race
condition ending up with a dealock.
I later version is this removed, BUT:
If you are using device-mapper with udev enabled, its need to synchronise
device node creation, which happens from the last dm udev-rule, but you are blocked
in rule before -> deadlock -> timeout (maybe).
It's a little bit more complicated, I think. If udev would care for
ordering of events, doing them synchronously, you would probably be
right, then again, you would not need any synchronization to avoid a
race condition. (Imho it is a blatant maldesign that uevent does not
provide real event based programming and an apropriate API, but that's a
different story).
Usually what I would expect to happen: usb device is added - uevent is
created, udev calls cryptsetup during processing of uevent, crypsetup
does dm setup and waits for completion of inode creation - is this done
via an IOCTL? During this process more uevents are created. Since there
is no synchronization the new uevent is passed down to udevd and the
apropriate action is taken (i.e. create symbolic name, whatsoever).
cryptsetup can terminate and thus processing of the previously generated
uevent finishes.
This is even true when you do not use udev, since for any uevent
/sys/proc/hotplug when set is executed at the time it occurs. There is
neither ordering nor any synchronization.
Best do not do these operations from udev rule at all.
Maybe if it fork itself, it can work somehow. Anyway it is probably better
to not add such commands directly to udev rule, but in some other system
which registers for udev events (using some d-bus message or whatever).
Someone probably can suggest better desktop solution...
Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
Well, wasn't it exactly meant to be a hotplug processor in the first
place, not only a flexible inode name generator?
Just my 2 cent.
-Sven
P.S. To the original poster: Use an up to date version of cryptsetup.
Monitor uevents and their processing whilst plugging your harddisk, if
you still have a deadlock problem, this might help finding out why.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
