Device ID uses device directory name as is, hence may contain '!', but
sd_device_new_from_subsystem_sysname() expects that the input is sysname.
So, we need to replace '!' with '/'.
Follow-up for 1393c5a2a4.
Fixes#37711.
$ diff -u <(strings -n 10 build/libsystemd.so.0.40.0.0 | sort) <(strings -n 10 build/libsystemd.so.0.40.0 | sort)
--- /proc/self/fd/11 2025-05-31 15:17:16.968761963 +0200
+++ /proc/self/fd/12 2025-05-31 15:17:16.970159823 +0200
@@ -3860,11 +3860,6 @@
Failed to fstat() journal file '%s', ignoring: %m
Failed to fstat %s: %m
Failed to get basic: %m
-Failed to get device "ACTION" property, ignoring: %m
-Failed to get device "DEVNUM" property, ignoring: %m
-Failed to get device "DISKSEQ" property, ignoring: %m
-Failed to get device "IFINDEX" property, ignoring: %m
-Failed to get device "SEQNUM" property, ignoring: %m
Failed to get device "%s" property, ignoring: %m
Failed to get inode number of pidfd for pid %i: %m
Failed to get peer's socket address, ignoring: %m
$ ls -l build/libsystemd.so.0.40.0{,.0}
-rwxr-xr-x 1 zbyszek zbyszek 7631640 May 31 15:16 build/libsystemd.so.0.40.0
-rwxr-xr-x 1 zbyszek zbyszek 7635736 May 31 15:16 build/libsystemd.so.0.40.0.0
$ size build/libsystemd.so.0.40.0{,.0}
text data bss dec hex filename
1241382 56185 3554 1301121 13da81 build/libsystemd.so.0.40.0
1241606 56185 3554 1301345 13db61 build/libsystemd.so.0.40.0.0
So the savings are ~4kB, which is more than I expected.
For libsystemd's headers, the changes made depend on whether the
header is installed or not. For installed headers, the only change
made is that commonly included headers were moved to _sd-common.h.
For these headers, there should be no noticeable change in behavior
when including them. For non-installed headers, includes were replaced
with forward declarations where possible as usual.
Split out of #37344.
For example, consider the following device:
- syspath: /sys/bus/mdio_bus/drivers/Qualcomm Atheros AR8031!AR8033
- subsystem: "drivers"
- driver subsystem: "mdio_bus"
- sysname: "Qualcomm Atheros AR8031/AR8033" <-- '!' is replaced with '/'
When sd_device_new_from_subsystem_sysname() is called to get the device,
the arguments to sd_device_new_from_subsystem_sysname() should be
- subsystem: "drivers"
- sysname (concatenated with driver subsystem): "mdio_bus:Qualcomm Atheros AR8031/AR8033"
In that case, we need to pass to device_new_from_path_join() the following:
- subsystem: "drivers"
- driver subsystem: "mdio_bus"
- sysname: "Qualcomm Atheros AR8031/AR8033"
- a: "/sys/bus"
- b: "drivers"
- c: "mdio_bus"
- d: "Qualcomm Atheros AR8031!AR8033"
Here, the important point is that the `sysname` argument and the
last argument `d` are differnt: the `sysname` argument needs to match
the sysname obtained by `sd_device_get_sysname()`, but `d` must be
the last path component of the syspath.
Previously, we passed a wrong sysname to device_new_from_path_join().
This fixes the issue.
Fixes a bug in cd7c71154c (v257).
The test "hangs" and times out on some arm64 machines. It actually works as
expected, but the machine has 2016 children under /sys/devices/system/memory/,
and the tests do a double loop over this, which is slow enough to hit the 120 s
limit. Add a limit on the number of iterations.
Another option would be to exclude "memory" subsystem. But we may have other
subsystems which have the same problem in the future, so I think it'll be more
robust to not try to limit the fix to a specific subsystem.
- drop unnecessary one line function dump_device_action_table(),
- make parse_device_action() log about invalid action string,
- rename output argument of parse_device_action().
Previously, if e.g. DRIVER=foo is specified in uevent file, the value is
only saved as property, but was not set to sd_device.driver.
That was inconsistent to the case when a device is created through
netlink uevent.
Let's always set when we get e.g. sd_device.driver when DRIVER=foo
from both uevent file and netlink uevent.
This makes sd_device_get_sysattr_value()/sd_device_set_sysattr_value()
refuse to read/write files outside of sysfs for safety.
Also this makes
- use chase() to resolve and open the symlink in path to sysfs attribute,
- use delete_trailing_chars(),
- include error code in cache entry, so we can cache more error cases,
- refuse caching value written to uevent file of any devices, i.e.
sd_device_set_sysattr_value(dev, "../uevent", "add") will also not
cache the value "add".
Even though udevadm accepts relative syspath, previously, udevadm
could not use relative path to device node:
===
$ cd /dev
$ udevadm info sda
Bad argument "sda", expected an absolute path in /dev/ or /sys/ or a unit name: Invalid argument
$ udevadm info /usr/../dev/sda
Unknown device "/usr/../dev/sda": No such device
===
With this change, both the above cases work fine.
Note, still sd_device_new_from_devname() requires absolute path starts
with /dev/, for safety.
Devices under /sys/firmware/ do not have subsystems. Hence, the
validation in sd_device_new_from_subsystem_sysname() ->
device_new_from_path_join() always failed.
Fixes a bug introduced by cd7c71154c (v257).
Fixes#35861.
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Luca Boccassi
Daan De Meyer
Jelle van der Waa
anonymix007