Re: [dm-devel] [PATCH 1/3] Send KOBJ_ADD event after dm resume ioctl.

[Milan Broz <mbroz redhat com>]

On 03/19/2010 12:44 PM, Kay Sievers wrote:
> On Fri, Mar 19, 2010 at 12:14, Milan Broz <mbroz redhat com> 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?

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.]

> 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.

Anyway, this name/uuid information is in sysfs now.
But not the VG/LV symlinks info which is pure userspace abstraction...

Milan
--
mbroz redhat com