IIUC, with MAX() we get a VLA and the size is "decided" at runtime,
even though the result is always the same, but with CONST_MAX() we
get a normal stack variable.
The general rule should be to be strict when parsing data, but lenient
when printing it. Or in other words, we should verify data in verification
functions, but not when printing things. It doesn't make sense to refuse
to print a value that we are using internally.
We were tripping ourselves in some of the print functions:
we want to report than an address was configured with too-long prefix, but
the log line would use "n/a" if the prefix was too long. This is not useful.
Most of the time, the removal of the check doesn't make any difference,
because we verified the prefix length on input.
IN6_ADDR_TO_STRING(…) always returns something, so we can simplify the code a
lot. Also, let's not do step-wise concatenation, but instead handle everything
with one str_extendf() call.
Since we don't need the error value, and the buffer is allocated with a fixed
size, the whole logic provided by in_addr_to_string() becomes unnecessary, so
it's enough to wrap inet_ntop() directly.
inet_ntop() can only fail with ENOSPC. But we specify a buffer that is supposed
to be large enough, so this should never fail. A bunch of tests of this are added.
This allows all the wrappers like strna(), strnull(), strempty() to be dropped.
The guard of 'if (DEBUG_LOGGING)' can be dropped from around log_debug(),
because log_debug() implements the check outside of the function call. But
log_link_debug() does not, so it we need it to avoid unnecessary evaluation of
the formatting.
This reverts commit 0bd292567a.
It isn't guaranteed anywhere that __builtin_dynamic_object_size can
always deduce the size of every object passed to it so systemd
can end up using either malloc_usable_size or
__builtin_dynamic_object_size when pointers are passed around,
which in turn can lead to actual segfaults like the one mentioned in
https://github.com/systemd/systemd/issues/23619.
Apparently __builtin_object_size can return different results for
pointers referring to the same memory as well but somehow it hasn't
caused any issues yet. Looks like this whole
malloc_usable_size/FORTIFY_SOURCE stuff should be revisited.
Closes https://github.com/systemd/systemd/issues/23619 and
https://github.com/systemd/systemd/issues/23150.
Reopens https://github.com/systemd/systemd/issues/22801
../src/journal-remote/microhttpd-util.c: In function ‘check_permissions’:
../src/journal-remote/microhttpd-util.c:301:5: error: function might be candidate for attribute ‘noreturn’ [-Werror=suggest-attribute=noreturn]
301 | int check_permissions(struct MHD_Connection *connection, int *code, char **hostname) {
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Fixes#23630.
We're already using C.UTF-8 as the default locale for nspawn. Let's
make the same change for the default-locale option instead of deciding
what to use based on the locale used by the host system. Users can
still override the locale using the default-locale option if needed.
If rngd is included in the host initrd, QEMU guests need at least one source of
entropy otherwise rngd will refuse to start. Hence this patch enables the
virtio RNG device in QEMU guests (exposed as a HW RNG device available at
/dev/hwrng).
As a safety measure, the patch limits the data sent to the guest to 1KB per
second in order to not let the guest starve the host entropy.
In file included from ../src/basic/siphash24.h:11,
from ../src/basic/hash-funcs.h:6,
from ../src/basic/hashmap.h:8,
from ../src/shared/fdset.h:6,
from ../src/shared/bpf-program.h:9,
from ../src/core/unit.h:11,
from ../src/core/all-units.h:4,
from ../src/core/manager.c:23:
../src/basic/time-util.h: In function 'manager_dispatch_jobs_in_progress':
../src/basic/time-util.h:140:38: error: 'x' may be used uninitialized [-Werror=maybe-uninitialized]
140 | #define FORMAT_TIMESPAN(t, accuracy) format_timespan((char[FORMAT_TIMESPAN_MAX]){}, FORMAT_TIMESPAN_MAX, t, accuracy)
| ^~~~~~~~~~~~~~~
In function 'manager_print_jobs_in_progress',
inlined from 'manager_dispatch_jobs_in_progress' at ../src/core/manager.c:3007:9:
../src/core/manager.c:219:18: note: 'x' was declared here
219 | uint64_t x;
| ^
cc1: all warnings being treated as errors
For some reason this (false positive) warning starts appearing after
-ftrivial-auto-var-init is used.
When something goes awry, we would get identical log messages from all the
bpf subsystems. E.g. "Failed to load BPF object: %m" appeared 5 times in the
sources. But it is very important to know *which* object we failed to load.
This could be guessed, e.g. from surroudning messages or from filename/line
metadata, but when we get log messages in bug reports, this might not be
available. Let's make the messages distinguishable.
While at it, some messages were adjusted a bit. In particular, we shouldn't use
internal names like BPFProgram which have no meaning outside of the codebase.
Testing the error paths is very important. If we are not root, we should
try and get a failure, which we should report nicely and mark the test
as skipped. After those checks are removed, this is what seems to happen.
This way we can see what will happen e.g. in the user manager when we try
to perform some bpf ops.
$ build/test-socket-bind
...
libbpf: load bpf program failed: Operation not permitted
libbpf: failed to load program 'sd_bind4'
libbpf: failed to load object 'socket_bind_bpf'
libbpf: failed to load BPF skeleton 'socket_bind_bpf': -1
Failed to load BPF object: Operation not permitted
Now all lines with "libbpf:" are at debug level and will be hidden by
default.
Partially fixes https://bugzilla.redhat.com/show_bug.cgi?id=2084955#c14
(i.e. the error that was exposed when the initial error was fixed.)
