Builds with kernels headers < 4.14 fail with:
../src/shared/loop-util.c: In function ‘loop_configure_fallback’:
../src/shared/loop-util.c:237:31: error: ‘LOOP_SET_BLOCK_SIZE’ undeclared (first use in this function); did you mean ‘LOOP_SET_DIRECT_IO’?
if (ioctl(fd, LOOP_SET_BLOCK_SIZE, (unsigned long) c->block_size) < 0)
^~~~~~~~~~~~~~~~~~~
LOOP_SET_DIRECT_IO
Fixes: https://github.com/systemd/systemd/issues/33341
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Also, make sure the NUL byte iovec becomes an exported constant too.
This is better than the previous situation where this was a macro
resolving to a compount expression, since the lifetime of the expression
is limited to its invoking scope. By turning this into a proper variable
the lifetime becomes unbounded, which makes it easier to use in various
scenarios, such as "if" blocks.
When looking at how dlopen for various libs is implemented, I found that the
macros hide too much. I find it much easier to see what is going on if 'extern'
and '= NULL' are written explicitly. After all, we don't hide those for other
definitions, e.g. our style guide says that static variables should be
initialized with '= NULL'. With that change, it's much more obvious what is
a variable declaration and what is a variable initialization.
- add missing assertions,
- use GREEDY_REALLOC() at one more place,
- etc.
Before:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==112572== Memcheck, a memory error detector
==112572== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==112572== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==112572== Command: ./systemd-hwdb update
==112572==
==112572==
==112572== HEAP SUMMARY:
==112572== in use at exit: 0 bytes in 0 blocks
==112572== total heap usage: 1,320,113 allocs, 1,320,113 frees, 70,614,501 bytes allocated
==112572==
==112572== All heap blocks were freed -- no leaks are possible
==112572==
==112572== For lists of detected and suppressed errors, rerun with: -s
==112572== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
21.94user 0.19system 0:22.23elapsed 99%CPU (0avgtext+0avgdata 229876maxresident)k
0inputs+25264outputs (0major+57275minor)pagefaults 0swaps
```
After:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
[sudo] password for watanabe:
==114732== Memcheck, a memory error detector
==114732== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==114732== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==114732== Command: ./systemd-hwdb update
==114732==
==114732==
==114732== HEAP SUMMARY:
==114732== in use at exit: 0 bytes in 0 blocks
==114732== total heap usage: 1,276,406 allocs, 1,276,406 frees, 68,500,491 bytes allocated
==114732==
==114732== All heap blocks were freed -- no leaks are possible
==114732==
==114732== For lists of detected and suppressed errors, rerun with: -s
==114732== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
21.91user 0.24system 0:22.26elapsed 99%CPU (0avgtext+0avgdata 233584maxresident)k
0inputs+25168outputs (0major+58237minor)pagefaults 0swaps
```
This allows us to reserve a bunch of capacity ahead of time,
improving the performance of hwdb significantly thanks to not
having to reallocate so many times.
Before:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==113297== Memcheck, a memory error detector
==113297== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==113297== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==113297== Command: ./systemd-hwdb update
==113297==
==113297==
==113297== HEAP SUMMARY:
==113297== in use at exit: 0 bytes in 0 blocks
==113297== total heap usage: 1,412,640 allocs, 1,412,640 frees, 117,920,009,195 bytes allocated
==113297==
==113297== All heap blocks were freed -- no leaks are possible
==113297==
==113297== For lists of detected and suppressed errors, rerun with: -s
==113297== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
132.44user 21.15system 2:35.61elapsed 98%CPU (0avgtext+0avgdata 228560maxresident)k
0inputs+25296outputs (0major+6886930minor)pagefaults 0swaps
```
After:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==112572== Memcheck, a memory error detector
==112572== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==112572== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==112572== Command: ./systemd-hwdb update
==112572==
==112572==
==112572== HEAP SUMMARY:
==112572== in use at exit: 0 bytes in 0 blocks
==112572== total heap usage: 1,320,113 allocs, 1,320,113 frees, 70,614,501 bytes allocated
==112572==
==112572== All heap blocks were freed -- no leaks are possible
==112572==
==112572== For lists of detected and suppressed errors, rerun with: -s
==112572== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
21.94user 0.19system 0:22.23elapsed 99%CPU (0avgtext+0avgdata 229876maxresident)k
0inputs+25264outputs (0major+57275minor)pagefaults 0swaps
```
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension
that enables a TCP connection to use different paths. It allows a device
to make use of multiple interfaces at once to send and receive TCP
packets over a single MPTCP connection. MPTCP can aggregate the
bandwidth of multiple interfaces or prefer the one with the lowest
latency, it also allows a fail-over if one path is down, and the traffic
is seamlessly re-injected on other paths.
To benefit from MPTCP, both the client and the server have to support
it. Multipath TCP is a backward-compatible TCP extension that is enabled
by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...).
Multipath TCP is included in the Linux kernel since version 5.6 [2]. To
use it on Linux, an application must explicitly enable it when creating
the socket:
int sd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);
No need to change anything else in the application.
This patch allows MPTCP protocol in the Socket unit configuration. So
now, a <unit>.socket can contain this to use MPTCP instead of TCP:
[Socket]
SocketProtocol=mptcp
MPTCP support has been allowed similarly to what has been already done
to allow SCTP: just one line in core/socket.c, a very simple addition
thanks to the flexible architecture already in place.
On top of that, IPPROTO_MPTCP has also been added in the list of allowed
protocols in two other places, and in the doc. It has also been added to
the missing_network.h file, for systems with an old libc -- note that it
was also required to include <netinet/in.h> in this file to avoid
redefinition errors.
Link: https://www.rfc-editor.org/rfc/rfc8684.html [1]
Link: https://www.mptcp.dev [2]
Currently the check also succeeds if the input path starts with a dot, whereas
we only want it to succeed for "." and "./". Tighten the check and add a test.
Import magic.h from Linux 6.9 to get the definition of
BCACHEFS_SUPER_MAGIC. Update filesystems-gperf.gperf to add knowledge of
bcachefs.
This fixes the following error building against a bleeding edge kernel.
```
src/basic/meson.build:234:8: ERROR: Problem encountered: Unknown filesystems defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC
```
fd_cloexec_many promised to report if work was done, but that code was
not effective, because it always reported true if any fds were open.
But no callers care about the return value, so let's just drop this.
This makes output a bit shorter and nicer. For us, shorter output is generally
better.
Also, drop unnecessary UINT64_C macros. The left operand is always uint64_t,
and C upcasting rules mean that it doesn't matter if the right operand is
narrower or signed, the operation is always done on the wider unsigned type.
Opening pidfds for non thread group leaders only works from 6.9 onwards with PIDFD_THREAD. On
older kernels or without PIDFD_THREAD pidfd_open() fails with EINVAL. Since we might read non
thread group leader IDs from cgroup.threads, we introduce and set CGROUP_NO_PIDFD to avoid
trying open pidfd's for them and instead use the pid as is.
As per the documentation, EACCES is only returned when F_SETLK is
used, and only on some platforms, which doesn't seem to include
Linux:
https://github.com/torvalds/linux/blob/master/fs/locks.c
F_OFD_SETLK is documented to only return EAGAIN, and F_SETLKW/F_OFD_SETLKW
are blocking operations so this logic doesn't apply to them in the
first place.
Hence, only automatically convert EACCES into EAGAIN for F_SETLK
operations, and propagate the original error in the other cases.
This is important because in some cases we catch permission errors
and gracefully fallback, which is not possible if the original error
is lost.
This is an issue in practice because, due to a kernel bug present
before v6.2, AppArmor denies locking on file descriptors to LXC
containers. We support all currently maintained LTS kernels,
including v6.1, where despite a lot of effort and attempts over almost
a year, the bugfix still hasn't been backported, as it is complex and
requires large changes to AppArmor.
On affected kernels, all services running with PrivateNetwork=yes
fail and do not recover, instead of the normal behaviour of gracefully
downgrading to PrivateNetwork=no.
The integration tests in the Debian CI fail due to this issue:
https://ci.debian.net/packages/s/systemd/testing/arm64/46828037/
Currently, if proc_mounted() != 0, some functions
propagate -ENOENT while others return -EBADF.
Let's make things consistent, by introducing
a static inline helper responsible for finding out
the appropriate errno.
