udev: also make uevent blocked by events for the same device node
Even if the device node is the same, devnum (thus, device ID) and
syspath may be different. If a 'remove' and 'add' events for the same
device node but with different devnum and syspath are queued,
previously, we might process them in parallel. And, udev_watch_end() for
the 'remove' event and udev_watch_begin() for the 'add' event may
interfere each other.
udev: make newer event also blocked by DEVPATH_OLD
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.
Daan De Meyer [Tue, 3 May 2022 11:54:49 +0000 (13:54 +0200)]
sd-network: Keep inotify watch if watch descriptor didn't change
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.
tmpfiles: Split networkd entries into a separate file
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.
man: document that systemd-fstab-generator actually cares about roothash=/usrhash= on the kernel cmdline
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.
1449b0f8a96b27 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.
stat-util: ignore hidden_or_backup_file when checking if dir is empty
Commit https://github.com/systemd/systemd/commit/a068aceafbf
changed dir_is_emtpy_at to use FOREACH_DIRENT_IN_BUFFER instead of
FOREACH_DIRENT, but used dot_or_dotdot which just checks if the name
is literally '.' or '..' which is not enough, previous behaviour was
to ignore all hidden files, so restore that and add a test case.
meson: also check c_args to maybe add -Wno-maybe-uninitialized
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.
libsystemd-network: add assert about packet length
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.
pid1: search for creds in LoadCredential=/LoadCredentialEncrypted=
This adds support for searching for credentials more comprehensively.
Specifically, unless an absolute source path is specified we'll now
search for the credentials in the system credentials first, and then in
/etc/credstore/, /run/credstore/, and /usr/lib/credstore, making these
dirs hence the recommended place for credentials to leave in the system.
For LoadCredentialEncrypted= we'll also look into
/etc/credstore.encrypted/, /run/credstore.encrypted/, …. These dirs are
hence suitable for credentials whose provenience isn't trusted (e.g.
UEFI creds from systemd-stub), and thus require to be authenticated
before use.
pid1: import creds from sd-stub + qemu + kernel cmdline
Let's beef up our system credential game a bit, and explicitly import
creds from sd-stub, from qemu fw_cfg and the kernel cmdline and expose
them in the same way as those passed in from nspawn.
Specifically, this will imprt such credentials to
/run/credentials/@system (if the source can be trusted, as in the
qemu/kernel cmdline case) and /run/credentials/@encrypted (otherwise,
such as sd-stub provided ones).
Once imported we'll set the $CREDENTIALS_PATH env var for PID 1, like it
would be done by a container manager for the payload. (Conversely, we'll
also creat a symlink from /run/credentials/@system to whatever is set in
$CREDENTIALS_PATH in case we are invoked by a container manager, thus
providing a fixed path where system credentials are found).
pid1: load 'qemu_fw_cfg' kmod super early, so that we can import credentials from it
In one of the next commits we want to add support for importing system
credentials from qemu_fw_cfg, very early during boot. (So that we can
use the credentials therein for generators and even earlier). But that
means udev won#t load these modules for us, we have to load them
manually first.
man: beef up the description of systemd-oomd.service
The gist of the description is moved from systemd.resource-control
to systemd-oomd man page. Cross-references to OOMPolicy, memory.oom.group,
oomctl, ManagedOOMSwap and ManagedOOMMemoryPressure are added in all
places.
The descriptions are also more down-to-earth: instead of talking
about "taking action" let's just say "kill". We *might* add configuration
for different actions in the future, but we're not there yet, so let's
just describe what we do now.
test: exclude "bdi" subsystem and loop block devices
On several CI environments, it seems that some loop block devices and
corresponding bdi devices are sometimes removed during the test is
running. Let's exclude them.
compress: make Compression a regular non-sparse enum
Given we have two different types for the journal object flags and the
Compression enum, let's make the latter a regular non-sparse enum, and
thus remove some surprises. We have to convert anyway between the two,
and already do via COMPRESSION_FROM_OBJECT().
The compression helpers are used both in journal code and in coredump
code, and there's a good chance we'll use them later for other stuff.
Let's hence move them into src/basic/, to make them a proper internal
API we can use from everywhere where that's desirable. (pstore might be
a candidate, for example)
No real code changes, just some moving around, build system
rearrangements, and stripping of journal-def.h inclusion.
The idea was to catch CFLite regressions but since the action itself
pulls the latest docker images it can't be pinned properly and issues
like https://github.com/google/clusterfuzzlite/issues/91 are going to
pop up anyway. Let's unpin it by analogy with CIFuzz and hope it doesn't
break very often.