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

[Kay Sievers]

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

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