The `.mem_total` variable has `uint64_t` type, therefore, when multiplying the number
`20971512` by the number `1024` with the suffix `U`, we will not get the expected result of
`21,474,828,288`, since the number `20971512` without an explicit type indication has
`uint32_t` type.
First, multiplication will occur in accordance with the `uint32_t` type; this operation will
cause a **type overflow**, and only then will this result be assigned to a `uint64_t` type
variable.
It's worth adding the `UL` suffix to the number `20971512` to avoid **overflow**.
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Slepykh.
Let's be friendly in what we accept: whenever we define a JSON
structure, let's also allow decimal strings where we want an integer.
This patch purely replaces JSON_VARIANT_UNSIGNED by
_JSON_VARIANT_TYPE_INVALID in the various JsonDispatch[] tables, so that
we'll happily accept any type in json_dispatch(), so that
json_dispatch_uint64() and related tools can do their thing.
This does not switch over OCI (as a JSON structure not defined by us).
varlink_dispatch() is a simple wrapper around json_dispatch() that
returns clean, standards-compliant InvalidParameter error back to
clients, if the specified JSON cannot be parsed properly.
For this json_dispatch() is extended to return the offending field's
name. Because it already has quite a few parameters, I then renamed
json_dispatch() to json_dispatch_full() and made json_dispatch() a
wrapper around it that passes the new argument as NULL. While doing so I
figured we should also get rid of the bad= argument in the short
wrapper, since it's only used in the OCI code.
To simplify the OCI code this adds a second wrapper oci_dispatch()
around json_dispatch_full(), that fills in bad= the way we want.
Net result: instead of one json_dispatch() call there are now:
1. json_dispatch_full() for the fully feature mother of all dispathers.
2. json_dispatch() for the simpler version that you want to use most of
the time.
3. varlink_dispatch() that generates nice Varlink errors
4. oci_dispatch() that does the OCI specific error handling
And that's all there is.
This allows distros to install configuration file templates in /usr/lib/systemd
for example.
Currently we install "empty" config files in /etc/systemd/. They serve two
purposes:
- The file contains commented-out values that show the default settings.
- It is easier to edit the right file if it is already there, the user doesn't
have to type in the path correctly, and the basic file structure is already in
place so it's easier to edit.
Things that have happened since this approach was put in place:
- We started supporting drop-ins for config files, and drop-ins are the
recommended way to create local configuration overrides.
- We have systemd-analyze cat-config which takes care of iterating over
all possible locations (/etc, /run, /usr, /usr/local) and figuring out
the right file.
- Because of the first two points, systemd-analyze cat-config is much better,
because it takes care of finding all the drop-ins and figuring out the
precedence. Looking at files manually is still possible of course, but not
very convenient.
The disadvantages of the current approach with "empty" files in /etc:
- We clutter up /etc so it's harder to see what the local configuration actually is.
- If a user edits the file, package updates will not override the file (e.g.
systemd.rpm uses %config(noreplace). This means that the "documented defaults"
will become stale over time, if the user ever edits the main config file.
Thus, I think that it's reasonable to:
- Install the main config file to /usr/lib so that it serves as reference for
syntax and option names and default values and is properly updated on package
upgrades.
- Recommend to users to always use drop-ins for configuration and
systemd-analyze cat-config to view the documentation.
This setting makes this change opt-in.
Fixes#18420.
[zjs: add more text to the description]
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.
If there are no "ManagedOOMSwap" entries to monitor, then the event source
can be completely disabled. This scenario appears to be common and avoiding
the wake-ups can save idle energy consumption.
This was discovered while using Sysprof for various GNOME 45 performance
tuning. systemd-oomd goes from waking up a few times a second to no
wake-ups helping keep a laptop in deep(er) sleep.
Signed-off-by: Christian Hergert <chergert@redhat.com>
When closing the FILE handle attached to a memstream, it may attempt to
do a realloc() that may fail during OOM situations, in which case we are
left with the buffer pointer pointing to NULL and buffer size > 0. For
example:
```
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
void *realloc(void *ptr, size_t size) {
return NULL;
}
int main(int argc, char *argv[])
{
FILE *f;
char *buf;
size_t sz = 0;
f = open_memstream(&buf, &sz);
if (!f)
return -ENOMEM;
fputs("Hello", f);
fflush(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
fclose(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
return 0;
}
```
```
$ gcc -o main main.c
$ ./main
buf: 0x74d4a0, sz: 5, errno: 0
buf: 0x0, sz: 5, errno: 0
```
This might do unexpected things if the underlying code expects a valid
pointer to the memstream buffer after closing the handle.
Found by Nallocfuzz.
All daemons use a similar scheme to read their main config files and theirs
drop-ins. The main config files are always stored in /etc/systemd directory and
it's easy enough to construct the name of the drop-in directories based on the
name of the main config file.
Hence the new helper does that internally, which allows to reduce and simplify
the args passed previously to config_parse_many_nulstr().
Besides the overall code simplification it results:
16 files changed, 87 insertions(+), 159 deletions(-)
it allows to identify clearly the locations in the code where configuration
files are parsed.
Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
If the cgroup is owned by root there is no need to get prefix_uid. Only
check prefix_uid when uid != 0, and then set MANAGED_OOM_PREFERENCE_NONE
and return early if uid != prefix_uid.
This conditional with !empty_or_root(ctx->path) always returns false
because the most recent oomd_cgroup_context_acquire() call was with the
root cgroup. Make sure this test case can be reached by checking cgroup
instead of ctx->path.
While here, use an unused uid (61183) instead of the nobody uid so the
test case does not fail in unprivileged LXD containers.
Commit 652a4efb66 ("oomd: loosen the restriction on ManagedOOMPreference")
made the change to allow ManagedOOMPreference on a cgroup candidate when
the monitored cgroup and cgroup candidate are owned by the same user.
The commit assumed that this check was sufficient to continue allowing
ManagedOOMPreference on all cgroups owned by root. However, it caused a
regression for unprivileged LXD containers where e.g. /sys/fs/cgroup is
owned by nobody (uid=65534).
Fix this by explicitly allowing the ManagedOOMPreference if uid == 0 in
oomd_fetch_cgroup_oom_preference().
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
Building with GCC 12.2 and binutils 2.39 fails on riscv64 Ubuntu Kinetic
with:
FAILED: systemd-oomd
/usr/bin/ld: systemd-oomd.p/src_oom_oomd-util.c.o:
in function `oomd_cgroup_context_acquire':
build/../src/oom/oomd-util.c:415:
undefined reference to `__atomic_exchange_1'
We have to link with -latomic.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When we kill a cgroup that is towards the end of the sorted candidate
list (i.e. when we have to resort to killing a candidate with
ManagedOOMPreference=avoid), this cgroup is not logged in the candidate
list. This is due to an off-by-one error when assigning dump_until.
Add a new test function, test_oomd_fetch_cgroup_oom_preference, to test
the ManagedOOMPreference logic. For starters, cut the relevant tests out
of test_oomd_cgroup_context_acquire_and_insert, and add them to the new
function. Then, expand these tests to cover the new behavior.
The ManagedOOMPreference property is only honored on cgroups which are
owned by root. This precludes anyone from setting ManagedOOMPreference
on cgroups managed by user managers.
Loosen this restriction in the following way: when processing a
monitored cgroup for kill candidates, honor the ManagedOOMPreference
setting if the monitored cgroup and cgroup candidate are owned by the
same user. This allows unprivileged users to configure
ManagedOOMPreference on their cgroups without affecting the kill
priority of ancestor cgroups.
N.B. that since swap kill operates globally to kill the largest
candidate, it is not appropriate to apply this logic to the swap kill
scenario. Therefore, the existing restriction on ManagedOOMPreference
will remain when calculating candidates for swap kill.
Add a new function, oomd_fetch_cgroup_oom_preference, to assist with
this new logic. To simplify things, move the `user.oomd_{avoid,omit}`
xattr reads to this function so that the xattr reads and uid checks are
performed all at once.
The calculation for used memory in oomd_system_context_acquire is given
by MemTotal - MemFree from /proc/meminfo. This is too strict of a
calculation because it does not consider memory that is still available
for starting new applictions without swapping (MemAvailable). As a
result, systemd-oomd can start to kill processes before it is necessary.
This is more apparent on systems with low swap space.
Instead, compute 'used' memory as MemTotal - MemAvailable in
oomd_system_context_acquire and procfs_memory_get (which is used by
oomd_cgroup_context_acquire). And, rename oomd_mem_free_below to
oomd_mem_available_below for clarity.
To notify user of kill events from systemd-oomd we now use
`SERVICE_FAILURE_OOM_KILL` as the failure result.
`unit_check_oomd_kill` now calls `notify_cgroup_oom` to
update the service result to `oom-kill`.
We add a new xattr `user.oomd_ooms` to keep track of the OOM kills
initiated by systemd-oomd, this helps us resolve a race between sending
SIGKILL to processes and checking for OOM kill status from the xattr.
Related to: #20649
Lennart Poettering
Yu Watanabe
aslepykh
Franck Bui
Zbigniew Jędrzejewski-Szmek
Christian Hergert
Daan De Meyer
Frantisek Sumsal
David Tardon
Morten Linderud
Jan Janssen
Jade Lovelace
Nick Rosbrook
Heinrich Schuchardt
Oleg Solovyov
Michael Biebl
Nishal Kulkarni