DragonFlyBSD

dm_dev_lookup_uuid() returning non null for the second dmsetup create seems to be the reason for EEXIST.

The original Linux kernel implementation doesn't have this uuid logic, so this behavior seems to be (net)bsd specific.
This behavior doesn't make sense (at least to me), but not sure if this should be fixed nor is it trivial, so just leave it as it is for now.

dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch

===== with the existing code # kldload dm # dmsetup create linear1 --table '0 1000 linear /dev/da3 0' # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
ioctl create call failed: File exists

Command failed

1. dmsetup create zero1 --table '0 100 zero'
   ioctl create call failed: File exists

Command failed

1. dmsetup create error1 --table '0 100 error'
   ioctl create call failed: File exists

Command failed

1. ls /dev/mapper
   control linear1

===== with this commit # kldload dm # dmsetup create linear1 --table '0 1000 linear /dev/da3 0' # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' # dmsetup create zero1 --table '0 100 zero' # dmsetup create error1 --table '0 100 error' # ls /dev/mapper
control delay1 error1 linear1 zero1