On Fri, Mar 19, 2010 at 13:08, Milan Broz <mbroz@xxxxxxxxxx> wrote: > On 03/19/2010 12:44 PM, Kay Sievers wrote: >> On Fri, Mar 19, 2010 at 12:14, Milan Broz <mbroz@xxxxxxxxxx> wrote: >>> On 03/19/2010 11:16 AM, Kay Sievers wrote: >>> Well. And what should happen if anyone generate >>> artificial CHANGE event before the real first CHANGE event comes from >>> subsystem? (yes, I am looking at you, OPTIONS+="watch" thing for example) >> >> We retrieve the device state and if it's not ready, we just exit. > > How? By scanning/opening it? > > Scan on uninitialised device can lock the device and break initialisation, > "-EBUSY" - isn't it race? Whatever is appropriate, be it a control device node, sysfs, or the device itself. The simplest case would be the "size" check, MD checks a sysfs attribute, others just try to open. For dm we used to call dmsetup and rely on its returned information. > So all applications, which run some kind of configuration of device > should expect that device can be randomly locked by udev rules... > > [Yes, it happens. I solved several problems in cryptsetup where various > udev scans open and locks keyslot device. > (Ignoring the fact that it contains key material, in this case it was > not security problem - the material is still obfuscated.) > These are now masked in udev rules, but I do not like this approach much.] Yes, some tools may need to synchronize with the eventually running events. Plain udev does ignore all dm devices regarding the tools which open the device. It's all in the special subsystem rules, which might need to take care of synchronization. >> Yeah, usually it does not create any meta-information besides the >> primary device node. > > Unfortunately it is not the DM/LVM etc case - we had always symlinks > and long device names etc. But these are passed from an earlier event run. Usually they are just retrieved the same way again. Kay -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
