Previously, a device has DEVPATH_OLD is blocked by a previous event
whose devpath is equivalent to the DEVPATH_OLD.
This extends the condtion.
1. an event has DEVPATH_OLD is blocked by a previous event whose
devpath is a parent of, child of, or equivalent to the DEVPATH_OLD.
2. an event is blocked by a previous event whose DEVPATH_OLD is a
parent of, child of, or equivalent to the devpath of the new event.
I am not sure such check is really necessary. But, the cost of the check
is expected to be extremely small, as device renaming does not occur so
frequently. Hence, it should not introduce any significant performance
regression.
If two devices have the same devnum and subsystem (more specifically,
if the device is block or not), or have the same ifindex, then IDs of
these devices are equivalent.
Hence, the previous conditions are covered by comparing device IDs.
Of course, events with a same ID should be already blocked by the
devpath check. So, this should not change anything.
However, udevd saves many kinds of data under /run/udev named with
the device ID. If multiple workers processes events for the same device
ID, then the database may become corrupted.
Let's explicitly check the device IDs for safety and simplicity.
In sd_network_monitor_flush(), we shouldn't remove the inotify
watch for the current directory if the directory the network
monitor is waiting for wasn't created yet.
inotify_add_watch() returns the same unique watch descriptor if a
path is already being watched. Let's return the watch descriptor
from monitor_add_inotify_watch() so we can check if it's the same
as the watch descriptor of the inotify event. If they are equal,
we're still watching the same path and we don't need to remove the
inotify watch just yet.
Many distributions ship systemd-networkd as a separate file so we
need to be able to ship the tmpfiles networkd entries as part of
that separate networkd package. Let's split the networkd entries
into a separate file to make that possible.
It doesn't really care about the hash value passed (which is processed
by systemd-veritysetup-generator), but it does care about the fact that
it is set (and mounts the DM nodes /dev/mapper/usr + /dev/mapper/root in
that case).
I don't know why this didn't occur to me earlier, but of course, it
*has* to be this data.
(This replaces some German prose about Berlin, that i guess only very
few people will get. With the new blob I think we have a much broader
chance of delivering smiles.)
Let's merge the footnote with the overall explanation of where systemd
parses its options from and reword the section a bit to hopefully make
things a bit more clear.
Many sandboxing options add implicit DeviceAllow rules, which might be confusing
for users running systemd-analyze security and not expecting it.
Print the list.
Fixes https://github.com/systemd/systemd/issues/23185
1449b0f8a9 fixed seccomp arch check for the offline case,
but broke it for the normal case, as when coming from D-Bus the
list of seccomp architectures is already converted to string.
Fixes https://github.com/systemd/systemd/issues/23224
People (and build systems) sometimes set flags through -Dc_args=… or $CFLAGS.
Let's catch this common case too. meson will set c_args from $CFLAGS, so we
only need to check the former.
We reject too-short packets in client_receive_message_raw(), so
the packets that dhcp_packet_verify_headers() gets are of sufficient size.
But let's add an assert to clarify this for the reader.
Closes#23223.
Yu Watanabe
Daan De Meyer
Evgeny Vereshchagin
rodin-ia
Lennart Poettering
dependabot[bot]
Jan Janssen
Alice S
techtino
Luca Boccassi
Zbigniew Jędrzejewski-Szmek