Overall size change for the whole series:
$ size build/systemd-networkd{.0,}
text data bss dec hex filename
1878634 394016 36 2272686 22adae build/systemd-networkd.0
1755066 394080 36 2149182 20cb3e build/systemd-networkd
i.e. 121 kb.
Structured initialization is used a bit more.
There were two kinds of log messages: about failed size calculations and
about failed appends to the message. I "downgraded" the first type to log_debug,
and moved the latter to the caller. This way there should be at most one high-priority
message.
I also changed sizeof(<type>) to sizeof(var) — there is less chance of select-and-paste
error in the second form.
All the detailed logging is replaced by a simple "Failed to create netlink message",
which should be enough for the user in the unlikely case that this ever fails.
This commit is the first in the series, and they generally follow the same
idea: we had very detailed logging for message append operations which would
only fail either with some type error or intrinsic limit (and then they would
fail everywhere, so this would be noticed during development or in CI), or they
would fail with ENOMEM, in which case the exact location is not very interesting
since this is not repeatable.
I am in general in favour of detailed logging messages, because it helps with
diagnosis of errors, but I think case is an exception. Despite not being very
useful, those messages required a lot of effort, because they were customized
for each and every append operation. In fact some of the messages contained copy
errors. The text of the messages (since they are generally unique) also added up
to a considerable size.
This removes the log messages after each sd_netlink_message_append_*() in
fill_message_create() with a single line in netdev_create(). As described
above, we are just appending fields to a message, so those calls would almost
never fail.
A forgotten 'return' was added in one place.
$ size build/systemd-networkd{.0,}
text data bss dec hex filename
1878634 394016 36 2272686 22adae build/systemd-networkd.0
1842450 394080 36 2236566 222096 build/systemd-networkd
… so we save 30k too.
If we're consuming an on-disk seed, we usually write out a new one after
consuming it. In that case, we might be at early boot and the randomness
could be rather poor, and the kernel doesn't guarantee that it'll use
the new randomness right away for us. In order to prevent the new
entropy from getting any worse, hash together the old seed and the new
seed, and replace the final bytes of the new seed with the hash output.
This way, entropy strictly increases and never regresses.
Fixes: https://github.com/systemd/systemd/issues/21983
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The code assume that meson's cpu_family can be mapped directly to
'-D__<cpu_family>__'. This works in a surprising number of cases, but not for a
few architectures. PPC uses "powerpc", and RISC-V omits the trailing underscores.
ARM and RISC-V require a second define too.
Fixes#21900.
(I don't think this matters too much: we need *something* so that gnu/stubs.h
can be successfully included. But we don't actually call syscalls or depend too
much on the host environment, so things should be fine as long as we don't get
a compilation error.)
When the support for "synthetic errno" was added, we started truncating
the errno value to just the least significant byte. This is generally OK,
because errno values are defined up to ~130.
The docs don't really say what the maximum value is. But at least in principle
higher values could be added in the future. So let's stop truncating
the values needlessly.
The kernel (or libbpf?) have an error where they return 524 as an errno
value (https://bugzilla.redhat.com/show_bug.cgi?id=2036145). We would
confusingly truncate this to 12 (ENOMEM). It seems much nicer to let
strerror() give us "Unknown error 524" rather than to print the bogus
message about ENOMEM.
The COREDUMP_EXE attribute is "optional", i.e. we continue to process the
crash even if we didn't acquire it. The coredump generation code assumed
that it is always available:
#5 endswith at ../src/fundamental/string-util-fundamental.c:41
[ endswith() is called with NULL here, and an assertion fails. ]
#6 submit_coredump at ../src/coredump/coredump.c:823
#7 process_socket at ../src/coredump/coredump.c:1038
#8 run at ../src/coredump/coredump.c:1413
We use the exe path for loop detection, and also (ultimately) pass it to
dwfl_core_file_report(). The latter seems to be fine will NULL, so let's just
change our code to look at COMM, which should be more reliable anyway.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2036517.
The code was written unidiomatically, using r as a boolean value, and
confusing errno and r in some places. AFAICS, there wasn't any actual
problem: even in the one place where errno was used instead of r, it would
almost certainly be initialized.
It seems that some libbpf functions set errno, while others return the
error, possibly encoded. Since there are almost no docs, the only way to
know is to read the code of the function. To make matters worse, there is
a global libbpf_mode which can be set to change the convention. With
LIBBPF_STRICT_DIRECT_ERRS in libbpf_mode, some functions set errno while others
return a negative error, and the only way to know is to read the code, except
that the split is now different. We currently don't set
LIBBPF_STRICT_DIRECT_ERRS, but even the possibility makes everything harder
to grok.
This is all very error-prone. Let's at least add some asserts to make sure that
the returned values are as expected.
