mount_option_supported() will call fsopen() which will probe the
kernel filesystem module. This means that we'll suddenly start
probing filesystem modules when running generators as those determine
which mount options to use. To prevent generators from loading kernel
filesystem modules as much as possible, let's always first check the
hardcoded list of filesystem which we know support a feature before
falling back to asking the kernel.
systemd's own cgroup hierarchy is special to us, we use it to actually
manage processes. Because of that many calls tha apply to cgroups are
only ever called with the SYSTEMD_CGROUP_CONTROLLER as controller
argument. Let's hence remove the argument altogether.
This in particular touches the kill and xattr routines.
This changes no behaviour, we just drop an argument that is always set
to the same value anyway.
This is preparation to eventually getting rid of the cgroupvs1, because
on cgroupvs2 the cgroup paths do not change for different controllers,
there's only a single hierarchy there.
Currently some of the code base check for the variable presence before
removing it, and some do not.
More so, in all cases (being updated) we're dealing with non-volatile
variables where changing those attribute to NVRAM wear out.
From what information I could find, there is no definitive answer if the
UEFI implementation will write to the NVRAM even when the variable is
missing.
So add a simple helper that checks for the variable presence before
removing it. While also having a bit cleaner API than the current
efivar_set(..., NULL, ...);
efivar_unset() follows the design from efivar_set*() where it returns an
EFI_STATUS even though its (presently) unused.
v2:
- add inline comment, use early return
v3:
- typos? typos!
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
In sd-dhcp-client.c, we do not set the option in the DHCPDISCOVER
message when anonymized, and the specified address is ignored
anyway. So, this does not change the behavior, but suppress
misleading debugging log in dhcp4_set_request_address().
And MMapFileDescriptor always references MMapCache, hence it is not
necessary Window to have a reference to MMapCache.
This also renames the list fields 'by_fd' -> 'windows', to make them
consistent with the name of the head.
No functional change, just refactoring.
The post operations (attach the found or new window to a context, update
the keep_always flag, and calculate the address) in three steps are
equivalent, and the two searching logics are quite simple.
Let's merge them to decrease the total lines.
No functional change, just refactoring.
This helps a lot with figuring out why units were started when they
were, rather than guessing there is a dependency relation. We could
perhaps also do fun JavaScript things in the future to highlight
dependencies on mouse-over.
This reverts the following commits.
- a1640191b4
- 231741d355
These were done by my misunderstanding of the mmap cache behavior.
Also, this updates the comments added by
df04b9ed86.
note that this slightly changes the semantic of assert when NDEBUG is
defined. if there's an extern function call (without attribute pure or
similar) then the compiler has to assume it has side effects and still
emit the function call.
whereas the old assert guaranteed that nothing will be evaluated on
NDEBUG.
Closes: https://github.com/systemd/systemd/issues/29408
This matches the change to tpm2_seal(), which now accepts a Tpm2Context instead
of a device string.
This also allows using the same TPM context for sealing and unsealing, which
will be required by (future) test code when sealing/unsealing using a transient
key.
Simplify the function with GREEDY_REALLOC_APPEND(). Also limit the size_t-sized
max value to UINT32_MAX since that's the maximum of the range this searches,
and the max parameter for tpm2_get_capability() is uint32_t.
The test expects TPM2_CC_FIRST - 1 and TPM2_CC_LAST + 1 to be unsupported, but
those are not necessarily invalid commands. Instead test known-invalid
commands. Also add some more valid commands.