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

[David Zeuthen]

Hey,

On Fri, Mar 19, 2010 at 10:34 AM, Alasdair G Kergon <agk at redhat.com> wrote:

> On Fri, Mar 19, 2010 at 09:58:00AM -0400, David Zeuthen wrote:
> > I think the problem is the that fact that 3rd party user space
> > opens the device before it is ready (e.g. just after ADD but before
> > the first CHANGE) makes things fall over.
> > This short-coming is what needs to get fixed, I think - it's very
> > fragile this way and since any random user / package can add
> > rules to open the device on add events, said user / package can
> > make device-mapper fail. Which doesn't exactly strike me
> > as robust behavior.
>
> And we suggested two potential solutions:
>
>  1 - change the kernel so the ADD event doesn't arrive until the device is
> ready for use.     [plus equivalent change for REMOVE]
>
>      Advantage: the dm device handling looks more like a real disk so we
> have
> less 'special case' code.  /dev then only indexes "dm devices ready to be
> used"
> rather than "dm devices registered in the kernel"
>
>      Disadvantage: breaks the currently-simple kobject/sysfs/dev linkage
> (as
> per Kay's earlier mail)


>
>  2 - several changes to the way udev rules are handled so we can choose to
> ignore events and make no changes to /dev, so we can override rules other
> packages insert without requiring dm-specific checks adding to them all,
> and
> probably some of the other things we've discussed on these various threads.
>

I don't think it's realistic to assume that user space will read and honor
something like a DM_UDEV_DISABLE_DM_RULES_FLAG property - while
we can make the udev package and other "core" OS packages do this, rules
from users, sites and random 3rd party packages will open() the device
on "add" (and, if properly written, also on "change").

It's much better to make that operation somehow gracefully fail in the
window where the device isn't configured. My understanding is that
we are not doing this today - for example, suppose I have this udev
rule

  SUBSYSTEM=="block", ACTION=="add|change", \
  IMPORT{program}="foo-check-for-some-signature $tempnode"

where foo-check-for-some-signature is some program to check for
a fs signature (say, for a properietary fs on a portable music
player device) and, if, so, set the FOO_* properties with specifics
about the device (these will be used in the UI to control/manage
the portable music player).

Things like this should work for any block device, no matter what
state it's in. Sure, for device-mapper block devices open() or
read() on the device may fail in the window between "add" and
"change" but that's fine.

What can never happen though, is that this configuration of the
device-mapper device somehow randomly fails because the
program foo-check-for-some-signature tries to open every block
device.

(Sure, user space can be _clever_ and save the fork+exec+open
by checking DM_UDEV_DISABLE_DM_RULES_FLAG from an
udev rule - but that's optimization, not something required for
correctness.)

I haven't checked if this problem still exists with device-mapper
but I know, in the past, that it has - and IIRC it was the reason
that you introduced DM_UDEV_DISABLE_DM_RULES_FLAG
after the udev ignore_device directive was removed.

I'd like to reiterate that it's actually not a problem that the sequence is

 - "add" uevent
 - device is not usable, access to the device fails gracefully
 - "change" uevent
 - device usable, blkid on the device etc. works

the point really is that you have to accept that there will exist
user space programs that does things on the device between
"add" and the initial "change" uevent.

The other problem, the assumption that "change" uevents only
originates from libdevmapper, is separate from this problem.

     David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20100319/fe155aa1/attachment.htm>