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


<br></div><div>Here is an example of the dmsetup command used to create the devices.</div><div><br></div><div># dmsetup create tap0 --table '0 47247164 linear /dev/xen/blktap-2/tapdev0 1'</div><div><br></div><div>


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


<div><br></div><div>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?</div><div><br></div><div>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.</div>


<div><br></div><div>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.</div><div><br></div><div>I hope this is the right place to ask this. If not please point me in the right direction.</div>


<div><br></div><div>Thanks, Nick.</div><div><br></div>