These are required by the bpf_tracing.h header in libbpf, see
https://github.com/libbpf/libbpf/blob/master/src/bpf_tracing.h.
bpf_tracing.h does have a few fallbacks in case __TARGET_ARCH_XXX
is not defined but recommends using the __TARGET_ARCH macros instead
so let's do that.
We calculate the amount of uncompressed data we can write by taking the limits
into account and halving it to ensure there's room for switching to compression
on the fly when storing cores on a tmpfs (eg: due read-only rootfs).
But the logic is flawed, as taking into account the size of the tmpfs storage
was applied after the halving, so in practice when an uncompressed core file
was larger than the tmpfs, we fill it and then fail.
Rearrange the logic so that the halving is done after taking into account
the tmpfs size.
Be explicit with the type, and more inline with our other code, that
likes to indicate the string char width in the name.
Also, switch to a fixed size type, since EFI variables should really be
binary exact the same on all archs.
These functions after all write EFI UTF-16 strings, i.e. are relatively
high-level, hence give them a specific name indicating the type, to
match our other helpers that have similar type suffixes.
Although being far from ideal and the first two test cases have to be run
before the setup phase otherwise they will fail, it still makes the test
suite look much better and easier to read
Let's make sure logind is accessible by the time user@.service runs, and
that logind stays around as long as it does so.
Addresses an issue reported here:
https://lists.freedesktop.org/archives/systemd-devel/2024-June/050468.html
This addresses an issued introduced by
278e815bfa, which dropped the a dependency
from user@.service systemd-user-sessions.service without replacement.
While dropping that dependency does make sense, it should have been
replaced with the weaker dependency on systemd-logind.service, hence fix
that now.
user@.service is after all a logind concept, hence logind really should
be around for its lifetime.
systemd-user-sessions.service is a later milestone that only really
should apply to regular users (not root), hence it's too strong a
requirement.
read_virtual_file() will only read up to page size bytes of data
from /sys/firmware/dmi/entries/.../raw so let's use read_full_file_full()
instead to make sure we read all data.
This should be safe since smbios11 data can be considered immutable
during the lifetime of the system.
Various of our tools operate on block devices, and it's not always
obvious to know which block devices are actually appropriate for use.
Hence, let's add a helper that allows to list block devices, and
supports some limited filtering.
In the unlikely event that sandboxes block statx() but let
name_to_handle_at() through it's a good way to determine the root inode
of the namespace, since its parent inode will have the same FID and
mnt_id.
Newer kernels support a new flag for name_to_handle_at(): AT_HANDLE_FID.
This flag is supposed to return an identifier for an inode that we can
use for checking inode identity. It's supposed to be a replacement for
checking .st_ino which doesn't work anymore today because inode numbers
are no longer unique on file systems (not on overlayfs, and not on btrfs
for example). Hence, be a good citizen and add infrastructure to support
AT_HANDLE_FID. Unfortunately that doesn't work for old kernels, hence
add a fallback logic: if we can use the flag, use it. If we cannot use
name_to_handle_at() without it, which might give us a good ID too. But
of course tha tcan fail as well, which callers have to check.
And while we are at it, make it use ERRNO_IS_xyz() where appropriate.
And move it up a bit, so we can use in the whole of mountpoint-util.c
(which we want to later).
cpu.pressure 'full' is undefined for system-wide checks since 5.13 but still reported with values set to 0 for backwards compatibility. Made changes to reflect this for system-wide checks so that the conditional comparison is not made against the 0 value and instead fall back to 'some'.
https://www.kernel.org/doc/html/latest/accounting/psi.html
If the destination mount point is on a shared filesystem and is
missing on the first attempt, we try to create it, but then
fail with -EEXIST if something else created it in the meanwhile.
Enter the retry logic on EEXIST, as we can just use the mount
point if it was already created.
Fixes https://github.com/systemd/systemd/issues/29690
