I left this one as a separate commit because it is more involved.
We want people to compile with valgrind support, but we don't want to
use a slow hash function unless we're actually running under valgrind.
So the compile-time check is changed to a runtime check. When compiled
with optimization, the compiler should elide the checks on the constants,
and only leave the check for RUNNING_ON_VALGRIND. It is wrapped with
_unlikely_ so that the else branch is put in the hot path.
meson: merge our two valgrind configuration conditions into one
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we
would enable if the valgrind headers were found. The operations then we be
conditionalized on RUNNING_UNDER_VALGRIND.
But in a few places we had code which was conditionalized on VALGRIND, i.e. the
config option. I noticed because I compiled with -Dvalgrind=true on a machine
that didn't have valgrind.h, and the build failed because
RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that
the header is present if the option is set, but it seems better to just remove
the option. The code to support valgrind is trivial, and if we're
!RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under
valgrind is always some special testing/debugging mode, so we should just do
those extra steps to make valgrind output cleaner. Removing the option makes
things simpler and we don't have to think if something should be covered by the
one or the other configuration bit.
I had a vague recollection that in some places we used -Dvalgrind=true not
for valgrind support, but to enable additional cleanup under other sanitizers.
But that code would fail to build without the valgrind headers anyway, so
I'm not sure if that was still used. If there are uses like that, we can
extend the condition for cleanup_pools().
I'm not sure what "suffix" was meant by this comment, but the file has the usual suffix.
The file was added with the current name back in c4708f132381e4bbc864d5241381b5cde4f54878.
Maybe an earlier version of the patch did something different.
meson: adjust whitespace handling in jinja2 rendering
In 6abe882bae1bb12827ef395c60f21ab8bb1bc61b the renderer was made to
unconditionally append a newline to output. This works, but is ugly. A nicer
solution is to tell jinja2 to not strip the newline in the first place, via
keep_trailing_newline=True. It seems that the result is unchanged because all
our source files have exactly one trailing newline.
Also, enable lstrip_blocks=True. This would cause whitespace on the line before
an {%if block to be automatically stripped. It seems reasonable to enable that
if trim_blocks=True.
Overall, no change is expected, though I didn't test combinations of
configurations, so there might be a change in some cases. But now the rules of
rendering are more logical, e.g. we should be able to indent nested conditional
statements without getting unexpected whitespace in the output.
We should be more careful with distinguishing the cases "all bits set in
caps mask" from "cap mask invalid". We so far mostly used UINT64_MAX for
both, which is not correct though (as it would mean
AmbientCapabilities=~0 followed by AmbientCapabilities=0) would result
in capability 63 to be set (which we don't really allow, since that
means unset).
cap-list: make sure never to accidentally return more than 63 caps
The rest of our codebase stores caps masks in a uint64_t, and also
assumes UINT64_MAX was a suitable value for "unset mask". Hence refuse
any caps outside of 0…62.
(right now the kernel knows 40 caps, hence 22 more to go before we have
to reconsider our life's choices.)
We refuse it otherwise currently, simply because we cannot store it in a
uint64_t caps mask value anymore while retaining the ability to use
UINT64_MAX as "unset" marker.
The check actually was in place already, just one off.
shared/hwdb-util: drop "variable" with a single use
In 6a34639e76b8b59233a97533b13836d5a44e8d4a arg_hwdb_bin_dir was replaced by
default_hwdb_bin_dir, which is constant. Generally we'd use a #define instead,
but since there's just one use, let's just avoid the indirection altogether.
Yu Watanabe [Sat, 18 Feb 2023 22:15:02 +0000 (07:15 +0900)]
udev-node: drop unnecessary initialization
The priority of device node symlink can be negative. So the
initialization is confusing.
Fortunately, this changes no functionality, as we only compare the
priorities of symlinks only when we parsed at least one device node and
its priority.
Frantisek Sumsal [Mon, 20 Feb 2023 09:50:06 +0000 (10:50 +0100)]
test: ignore missing coverage in TEST-78
gcov is incompatible with DynamicUser=true without additional tweaks, so
let's ignore its complaints in this test, as working around it is not
worth it (in this case).
Mike Yuan [Sat, 18 Feb 2023 13:49:21 +0000 (21:49 +0800)]
journalctl: fix output when --lines is used with --grep
Previously, we skip the entries before arg_lines
unconditionally, which doesn't behave correctly
when used with --grep. After this commit, when
a pattern is specified, we don't skip the entries
early, but rely on the count of the lines shown
to tell us when to stop. To achieve that we would
have to search backwards instead.
mempool: rework mempool_cleanup() to only release freed tiles
This substantially reworks mempool_cleanup() so that it releases pools
with all freed tiles only, but keeps all pools with still-allocated
tiles around.
This is more correct, as the previous implementation just released all
pools regardless if anything was still used or not. This would make
valgrind shut up but would just hide memory leaks altogether. Moreover
if called during regular runtime of a program would result in bad memory
accesses all over.
Hence, let's add a proper implementation and only trim pools we really
know are empty.
This way we can safely call these functions later, when under memory
pressure, at any time.
Dan Streetman [Mon, 19 Dec 2022 14:58:05 +0000 (09:58 -0500)]
tpm2: simplify tpm2_seal() blob creation
TPM2 marshalling will never increase the total size, only possibly decrease.
There is no need for checking for insufficient size if the buffer size
is set to the sizeof both objects to be marshalled.
sd-event: allocate event source objects with the actually needed size
Currently we allocate fixed-size memory for event sources: the largest
any of the event source type needs. Discrepancy in the sizes needed for
the various event sources is quite major however: it's 144 bytes on
x86_64, i.e. more than two cache lines.
hence, let's be a tiny bit more careful, and allocate exactly as much as
we need, but not more.
systemctl: add --kill-value= argument to systemctl
This allows accompanying a signal with a value (as supported for Linux
Realtime signals). This is particularly useful as it allows us to do
stuff like this:
Yu Watanabe [Fri, 17 Feb 2023 01:21:58 +0000 (10:21 +0900)]
test-execute: also mount tmpfs on /dev/shm
Otherwise, if /dev/shm has a directory that cannot be accessible by
unprivileged user, then we cannot pick a dynamic user, and test service
may fail with unexpected error code:
---
Failed to enter shared memory directory /dev/shm/systemd-watch-bind-BqAGlN: Permission denied
exec-dynamicuser-supplementarygroups.service: Failed to update dynamic user credentials: Device or resource busy
exec-dynamicuser-supplementarygroups.service: Failed at step USER spawning /bin/sh: Device or resource busy
src/test/test-execute.c:885:test_exec_dynamicuser: exec-dynamicuser-supplementarygroups.service: can_unshare=no: exit status 217, expected 216
---
Frantisek Sumsal [Thu, 16 Feb 2023 18:48:03 +0000 (19:48 +0100)]
test: avoid matching other fields than __SEQNUM=
The current unanchored grep sometimes matches MESSAGE=/_CMDLINE= fields
that contain "__SEQNUM=" instead of just the __SEQNUM= field, causing
spurious test fails:
Jan Janssen [Thu, 16 Feb 2023 14:24:44 +0000 (15:24 +0100)]
boot: Fix assertion failure
The TPM code expects a description unless the PCR index indicates that
no measurements have to take place. The assert was preempting this
check from happening.
projects / thirdparty / systemd.git / log
