If reading the sysattr failed with such error, the whole operation in
net_id builtin command will fail, and the interface will not be renamed.
Fixes a bug introduced by 5bbcfbaa11.
If the lifetime of the route is already expired, do not try to
configure it.
Fixes a use-after-free, as the Request object is already freed, thus, we
cannot use Route or Link stored in Request object.
Otherwise, we provide misleading error message.
Before:
---
$ udevadm info /sys/class/foo
Bad argument "/sys/class/foo", expected an absolute path in /dev/ or /sys/ or a unit name: Invalid argument
---
After:
---
$ udevadm info /sys/class/foo
Unknown device "/sys/class/foo": No such device
---
Then, this makes loop_device_open_from_fd() or _from_path() be wrappers
of loop_device_open() with block_device_new_from_fd() or _from_path(),
respectively.
And split out the core logic as block_device_get_originating().
Hopefully, this changes no behavior. Just refactoring and preparation
for later commits.
TL;DR
This effectively reverts 8327fd1b11,
eaba9bb3e6, and its follow-ups, as the
original issue was already fixed by the kernel side.
The original issue that the above commits tried to 'fix' is that reading
phys_port_name triggers a lock in the kernel, hence processing multiple
interfaces at the same time causes extreme slow down.
To workaround the issue, the above commits made several necessary
information retrieved through netlink instead of sysfs attributes.
A patch set for the kernel was proposed as a fix for the issue:
https://lore.kernel.org/all/20210928125500.167943-1-atenart@kernel.org/
and some of them were merged to v5.16:
https://github.com/torvalds/linux/commit/146e5e733310379f51924111068f08a3af0db830,
It has been already backported to 5.4.160, 5.10.80, 5.14.19, and 5.15.3.
When these commits were proposed, it is already claimed that such issue
should be fixed by the kernel side, and udevd should not workaround it.
Neverthless the feature was introduced, as these have theoretical
performance improvement, even if phys_port_name sysattr does not have the
above issue, as in that way udevd can obtain multiple information about
the interface with a single netlink socket operation. See the discussion
in #20744.
However, in reality, only `iflink`, `type`, `address`, and `phys_port_name`
attributes from netlink are used in the udev net_id builtin command. Hence,
after the original issue being fixed in the kernel side, there should be
almost no performance improvement for udevd.
Furthermore, combining attributes from netlink and sysfs makes hard to
test net_id builtin. See #21725.
Let's drop mostly meaningless code, and make net_id builtin easily testable.
Closes#21725.
Fixes compile error with -Dopenssl=false.
```
In file included from ../../home/watanabe/git/systemd/src/shared/pkcs11-util.h:12,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:24:
../../home/watanabe/git/systemd/src/shared/openssl-util.h:56:21: error: conflicting types for ‘X509’; have ‘struct X509’
56 | typedef struct X509 X509;
| ^~~~
In file included from /usr/include/openssl/crypto.h:25,
from /usr/include/openssl/bio.h:20,
from /usr/include/openssl/asn1.h:16,
from /usr/include/openssl/ec.h:17,
from /usr/include/fido.h:10,
from ../../home/watanabe/git/systemd/src/shared/libfido2-util.h:18,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll-fido2.h:7,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:6:
/usr/include/openssl/ossl_typ.h:123:24: note: previous declaration of ‘X509’ with type ‘X509’ {aka ‘struct x509_st’}
123 | typedef struct x509_st X509;
| ^~~~
```
If multipath feature is enabled, nvme block devices may belong to the
"nvme-subsystem" subsystem, instead of "nvme" subsystem.
(What a confusing name...)
Then, the syspath is something like the following,
/sys/devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1
Hence, we need to find the 'real parent' device, such as
/sys/devices/pci0000:00/0000:00:1c.4/0000:3c:00.0/nvme/nvme0
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2031810.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2124964.
Replaces #24748.
Previously, existing device units for devlinks or aliases were not
removed unless the main device unit is removed. This makes all existing
device units for devlinks and aliases are checked if they are still
required, and remove if not necessary anymore.
Fixes#24518.
No functional changes, just refactoring.
Note, this also makes synthesize_change() propagate the error from
synthesize_change_one(). However, the caller of synthesize_change()
ignores the failure anyway, hence the change does not take any effect.
We already checked that the sd_device object 'dev' is for a whole block
device. So, -ENOENT should not be triggeered here, and if it is, there
exists something spurious. Hence we should not ignore the failure.
If the filename of a device symlink is too long, then the temporary
filename may become invalid, and we fail to create symlink.
The function `tempfn_random()` used in symlink_atomic_full() generates
a safe temporary filename.
Note that, thanks to the PR #23043, now only one worker can handle
the same symlink simultaneously. Hence, the device ID based temporary
filename is not necessary.
Yu Watanabe