Project

General

Profile

Actions

Bug #2843

closed

Fails to create dm device via dmsetup

Added by tkusumi over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
09/28/2015
Due date:
% Done:

0%

Estimated time:

Description

There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


  1. uname
    Linux
  2. dmsetup create zero1 --table '0 100 zero'
  3. ls -l /dev/mapper/zero*
    lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
  4. dmsetup create zero2 --table '0 100 zero'
  5. ls -l /dev/mapper/zero*
    lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
    lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

  1. uname
    DragonFly
  2. kldload dm
  3. dmsetup create zero1 --table '0 100 zero'
  4. ls l /dev/mapper/zero*
    crw-r----
    1 root operator 66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
  5. dmsetup create zero2 --table '0 100 zero'
    ioctl create call failed: File exists
Command failed
  1. ls l /dev/mapper/zero*
    crw-r----
    1 root operator 66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
Actions #1

Updated by tkusumi over 8 years ago

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.

Actions #2

Updated by tkusumi over 8 years ago

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

Actions

Also available in: Atom PDF