Red Hat Bugzilla – Bug 1263351
udev_device_new_from_subsystem_sysname unsuccessful in finding numerous devices
Last modified: 2018-02-14 18:05:38 EST
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): 219 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: None.
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.
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. """
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 "!".
I think that: <dev> == udev_device_new_from_subystem_sysname( context, udev_device_get_subsystem(<dev>), udev_device_get_sysname(<dev>) ) should hold true for all devices <dev>, but the attachment above illustrates that in some cases it does not.
What does "using the name given by udevadm" mean?
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 hpilo/d0ccb0 iLO [root@megadeth reproducers]# echo $? 4 and [root@megadeth reproducers]# ./a.out event0 input [root@megadeth reproducers]# echo $? 0 ============================================================================= 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 E: MINOR=0 E: SUBSYSTEM=iLO 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: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: MAJOR=13 E: MINOR=64 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=736349 P is for path and N is for name?
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.
https://github.com/systemd/systemd/commit/a9ec9f29420623133c419ddc8864921a824751fb