Bug 1263351 - udev_device_new_from_subsystem_sysname unsuccessful in finding numerous devices
udev_device_new_from_subsystem_sysname unsuccessful in finding numerous devices
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: systemd-maint
Depends On:
  Show dependency treegraph
Reported: 2015-09-15 11:35 EDT by mulhern
Modified: 2018-02-14 18:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A small c file containing a slightly better example (1.09 KB, text/plain)
2015-10-05 08:19 EDT, mulhern
no flags Details

  None (edit)
Description mulhern 2015-09-15 11:35:20 EDT
Description of problem:

udev_device_new_from_subsystem_sysname does not seem to be able to find devices in unusual subsystems using the name given by udevadm. For some subsystems, it seems like no name sensibly derived from udevadm name works.

Version-Release number of selected component (if applicable):


How reproducible:

Consistently within a subsystem, but varies among different subsystems.

Steps to Reproduce:
1. Find a machine with devices in subsystem "iLO". Using name given by
udevadm, and also name with directory prefix truncated, method always returns NULL.
2. Find a machine with devices in subsystem input. udevadm reports name as, e.g., "input/event0", but lookup fails with this name. Need to synthesize name
by stripping "input/" prefix, at which point lookup succeeds. Seems like this
should be documented.
3. Find a machine with devices in subsystem "block" with name, e.g., "sda". Lookup works in this case.

Actual results:

Lookup doesn't work at all, or it is necessary to modify name as reported by udevadm to make it work.

Expected results:

Lookup should always work w/ unmodified name and unmodified subsystem name.

Additional info:

Comment 2 mulhern 2015-09-15 11:51:26 EDT
I think that probably the reason it doesn't work at all for case (1), and kind of works for case (2), is that for case (1) the subsystem name and the directory prefix are not the same, i.e., "iLO" and "hpilo/" where as for case (2) the subsystem name, "input", and the directory prefix are the same. But that may be entirely too simplistic.
Comment 3 mulhern 2015-09-22 10:45:27 EDT
For case (1), name given by udevadm is, e.g., hpilo/d0ccb1.
For case (2), name given by udevamd is, e.g., input/event0.

For case (1), basename of DEVPATH given by udevadm is, e.g., hpilo!d0ccb1.
For case (2), basename of DEVPATH given by udevadm is, e.g,, event0.

Lookup by the basename of the DEVPATH does seem to work correctly.

But that is hardly what the documentation says.

 Create new udev device, and fill in information from the sys device and the udev database entry. The device is looked up by the subsystem and name string of the device, like "mem" / "zero", or "block" / "sda".

The initial refcount is 1, and needs to be decremented to release the resources of the udev device. 
Comment 4 mulhern 2015-10-05 08:19 EDT
Created attachment 1079920 [details]
A small c file containing a slightly better example

Shows that lookup by sysname and subsystem obtained by appropriate libudev calls fails when the sysname should include a "!".
Comment 5 mulhern 2015-10-05 08:25:11 EDT
I think that:

<dev> == udev_device_new_from_subystem_sysname(

should hold true for all devices <dev>, but the attachment above illustrates that in some cases it does not.
Comment 6 Kay Sievers 2015-10-05 10:56:13 EDT
What does "using the name given by udevadm" mean?
Comment 7 mulhern 2015-10-05 11:50:58 EDT
Comments #5 and #4 give a much improved explanation of what I think is wrong.
So, udevadm could be left out of this entirely.

The output of the reproducer for the failing and for the successful runs are, respectively:

[root@megadeth reproducers]# ./a.out
[root@megadeth reproducers]# echo $?


[root@megadeth reproducers]# ./a.out
[root@megadeth reproducers]# echo $?


For the record, "the name given by udevadm" means the value prefixed by "N:" for a particular device in the output of "udevadm info --export-db" or similar calls.
Like this:

P: /devices/pci0000:00/0000:00:1c.2/0000:01:00.2/iLO/hpilo!d0ccb0
N: hpilo/d0ccb0
E: DEVNAME=/dev/hpilo/d0ccb0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:01:00.2/iLO/hpilo!d0ccb0
E: MAJOR=244

or like this:

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0/event0
N: input/event0
E: DEVNAME=/dev/input/event0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0/event0
E: TAGS=:power-switch:

P is for path and N is for name?
Comment 8 Kay Sievers 2015-10-05 12:05:10 EDT
The kernel translates '/' in device names to '!'. libudev translates them back
to '/', but udev_device_new_from_subsystem_sysname() does not doe any
translation. We could add that, I will check.

N: is for the device in /dev, it has no direct connection to sysname in /sys,
they are different for many devices, which is fine.

Note You need to log in before you can comment on or make changes to this bug.