- pass our system include directories to make generators use our libc
wrappers and latest kernel headers,
- include relevant headers in generated gperf file,
- use files() rather than find_program(), as the result of
find_program() cannot be passed to 'input' of custom_target(),
- move generate-bpf-delegate-configs.py to src/core/, as it is only used
by libcore.
- This introduces ERRNO_IS_FS_WRITE_REFUSED(), and apply it where
usable.
- This makes unexpected errors in access_fd() called by binfmt_mounted()
propagated to the caller.
- Renames binfmt_mounted() to binfmt_mounted_and_writable(), as it also
checks the fs is writable.
- Voidifies one disable_binfmt() call in shutdown.c.
The recently added test case TEST-07-PID1.subgroup-kill.sh surfaced a
race: if we enumerate PIDs in a cgroup, and the cgroup is unlinked at
the very same time reading will result in ENODEV. We need to handle that
gracefully. Hence let's do so.
Noticed while looking at:
https://github.com/systemd/systemd/actions/runs/16143084441/job/45554929264?pr=38120
We put the name of the variable in the message, but it is a local variable
and the name does not have global meaning. We end up with pointless copies
of the error string:
$ strings build/libsystemd.so.0.40.0 | grep 'big enough'
xsprintf: p[] must be big enough
xsprintf: error[] must be big enough
xsprintf: prefix[] must be big enough
xsprintf: pty[] must be big enough
xsprintf: mode[] must be big enough
xsprintf: t[] must be big enough
xsprintf: s[] must be big enough
xsprintf: spid[] must be big enough
xsprintf: header_priority[] must be big enough
xsprintf: header_pid[] must be big enough
xsprintf: path[] must be big enough
xsprintf: buf[] must be big enough
The error message already shows the file, line, and function name, which
is enough to identify the problem:
Assertion 'xsprintf: buffer too small' failed at src/test/test-string-util.c:20, function test_xsprintf(). Aborting.
Suggested in
https://github.com/systemd/systemd/pull/35892#discussion_r2180322856.
This is a tiny amount of code and does not warrant having a separate file
and spawning a separate instance of the compiler during the build.
Note: it took me a while to confirm that the contents of that table and
function don't end up in libsystemd.so. The issue is that they _are_ present in
it, unless LTO is used. We actually use link_whole[libbasic_static] for
libsystemd, so we end up with all that code there. LTO is needed to clean
that up.
Christian made this possible in Linux 6.15 with a new system call
open_tree_attr() that combines open_tree() and mount_setattr(). Because
idmapped mounts are (rightfully) not nested, we have to do some extra
shenanigans to make source we're putting the right source uid in the
userns for any idmapped mounts that we do in nspawn.
Of course we also add the necessary boilerplate to make open_tree_attr()
available in our code and wrap open_tree_attr() and the corresponding
fallback in a new function which we then use everywhere else.
These source files uses symbols provided by sys/stat.h, e.g. struct stat,
S_IFREG, S_IFBLK, and so on. Let's explicitly include sys/stat.h where
necessary.
Glibc's fcntl.h includes bits/stat.h, which provides these symbols, so
these symbols can be used without explicitly including sys/stat.h. But,
based on the discussion in #37922, we should explicitly include relevant
headers, and should not rely on the indirect inclusion.
Similar to 4f18ff2e29, but for sys/stat.h.
If one of the header is included in a C++ source file, then using
_Static_assert() triggers compile error for some reasons.
Let's use static_assert(), which can be used by both C and C++ code.
These source files uses symbols provided by sched.h, e.g.
setns(), unshare(), CLONE_NEWNS, and friends, but they do not explicitly
include sched.h. Currently, it is included indirectly via missing_syscall.h,
which is included by e.g. pidfd-util.h.
Let's explicitly include headers that provides symbols used in the code.
This is similar to 4f18ff2e29, but for sched.h.
- use unsigned for the return value of read_nr_open(), as it does not
fail, and the kernel internally uses unsigned for the value,
- when bumping the value by PID1, let's start from the kernel's maximum
value defined in fs/file.c. The maximum value should be mostly an API
of the kernel, but may changed in a future, hence still try several
times if we fail to bump the value.
Co-authored-by: Jared Baur <jaredbaur@fastmail.com>
Co-authored-by: John Rinehart <johnrichardrinehart@gmail.com>
Follow-up for c5de7b14ae
chase() is arguably a hot path in our code, hence it deserves
some caching whether open_tree() is available. Moreover,
the manual set of r to -EPERM feels kinda ugly. Let's
instead extract this bit into its own function.
As it turns out open() with O_PATH does *not* trigger autofs, you get a
reference to the autofs inode, if not triggered.
But there's a way out: open_tree() (when specified without
OPEN_TREE_CLONE) is actually fully equivalent to open() with O_PATH –
with the exception of one thing: it *does* trigger automounts.
Thanks for Christian Brauner for pointing me to this and saving my day.
Fixes: #33155
bus_append_unit_property() and associated functions accept a long list of
properties. But the specific names are only available through code. But it is
useful to be able to know the specific list of properties that is supported, in
particular for shell completions. Thus, add a way to list the properties that
are supported by the code.
In the future we could also turn this into a test for the documentation. For
various reasons, the list of properties listed in the docs is a partially
overlapping set. E.g. for service type, the pull request
https://github.com/systemd/systemd/pull/37661 creates a list with 212 entries,
and this code generates 7 entries less and 184 more. I didn't check all the
differences, but in the few cases I did, the list generated here was actually
correctly supported by 'systemd-run -p'.
A smoke test is added.
We're still discussing whether we want to remove this or not, but
regardless of whether we end up removing it or not, it's something
we add ourselves and as such should not live in our headers that
override glibc headers, so let's move it to fd-util.h.
This is not something that comes from glibc, but which we invent
ourselves. As such, it should not be part of our overrides of glibc
headers, but instead should be part of one of our own headers, so
let's move it to fd-util.h.
Follow up for 194a690181
Yu Watanabe
Lennart Poettering
DaanDeMeyer
Antonio Alvarez Feijoo
Matteo Croce
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Andres Beltran
Luca Boccassi