[dm-devel] /dev/mapper/<dm_name> symlink not being created

[Nicholas Nevin]

On Mon, May 14, 2012 at 9:43 AM, Zdenek Kabelac <zkabelac at redhat.com> wrote:

> Dne 12.5.2012 16:59, Nicholas Nevin napsal(a):
> > Anyone have any thoughts on this?
> >
> > Thanks, Nick.
> >
> > On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin at gmail.com>
> wrote:
> >
> >> In nightly testing of our product the tests do a fair bit of
> >> creating/destroying of device mapper devices and we have been seeing
> >> infrequent cases where the device is created OK but the corresponding
> >> /dev/mapper/<dm_name> symlink does not exist.
> >>
> >> Here is an example of the dmsetup command used to create the devices.
> >>
> >> # dmsetup create tap0 --table '0 47247164 linear
> /dev/xen/blktap-2/tapdev0
> >> 1'
> >>
> >> I managed to reproduce this problem with udev logging enabled and
> 'udevadm
> >> monitor' running and from the logs the cause appears to be that the udev
> >> add action (from the device create) and the udev change action (from
> when
> >> the device is resumed after loading the table) are running
> >> concurrently. The processing of the rules for the change action creates
> the
> >> /dev/mapper/tap0 symlink but then the processing of the add action
> deletes
> >> the symlink because /dev/mapper/tap0 is not in the add action DEVLINKS.
> >>
> >> The question I have is should dmsetup be ensuring that the add action
> >> completes before the change action is handled or is this behaviour
> expected?
> >>
> >> That /dev/mapper/tap0 is not in the DEVLINKS for the add action is
> AFAICT
> >> because of a race between the creation of the sysfs entries for the
> device
> >> and the processing of the add action in udevd. This can be fixed by
> >> sprinkling in some WAIT_FOR conditions in the dm udev rules. Our system
> is
> >> based on Ubuntu 12.04.
> >>
> >> I have attached the udevadm monitor output and the relevant piece of
> >> syslog for a test case where the /dev/mapper/tap0 symlink wasn't present
> >> when dmsetup returned.
> >>
> >> I hope this is the right place to ask this. If not please point me in
> the
> >> right direction.
>
> You have not specified version of lvm2 tools in use.
>

Ah yes, here we go.

root at nick-lt:~# lvm version
  LVM version:     2.02.66(2) (2010-05-20)
  Library version: 1.02.48 (2010-05-20)
  Driver version:  4.22.0
root at nick-lt:~# dmsetup version
Library version:   1.02.48 (2010-05-20)
Driver version:    4.22.0
root at nick-lt:~#



> But on udev system there are 2 options when nodes/links are created.
>
> By default it's on RESUME - since this is the moment table is defined,
> and proper messages are passed across udev system.
>
> For backward compatibility (and for non-udev systems) there is
> dmsetup create --addnodeoncreate  - which basically creates links on
> 'create'
> phase - but with old 'badness' behind - since normally no one should create
> nodes in /dev  - it's the  udev 'kingdom' which should not be externally
> modified (udev might not know about such entries).
>
> So the proper moment to work with created devices is after they have been
> resumed - everything else will be ugly udev hack with unpredictable
> results.


> Zdenek
>

Makes sense thanks. The problem seems to be though that the handling of the
add (on create) and change (on resume) actions coming from the kernel to
udevd
are not handled sequentially by udevd which can cause problems such I
described.
It seems to me that dmsetup should be ensuring that the add action upon
create
has been fully handled before doing the resume which generates the change
action.
I'm no expert though so I could well have things wrong here.

-nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20120515/17c2cdef/attachment.htm>