The commit 1cf4ed142d makes the IPv4 ACD
enabled unconditionally for IPv4 link-local addresses even if users
explicitly disable ACD.
This makes the IPv4 ACD is enabled by default, but honor user setting.
Fixes#22763.
It looks like the fix for https://github.com/github/codeql/issues/8409
is not yet in production (and the respective query needs to be enabled
in both the main and the PR branch to get results for it, hence why it
passed in #22837).
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
When we do mkdir, we should just use 0o777 and let the umask take care of the
rest. Specifying an explicit mode is inappropriate. And when touching the code,
let's replace black madness with normal python style.
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
When sorting paths it actually matters to use the right comparison
function. Example:
```
a/x
a-b/y
a_/z
```
I think people would probably expect this:
```
a/x
a-b/y
a_a/z
```
but if you use strcmp() instead of path_compare() you'd instead get:
```
a-b/y
a/x
a_a/z
```
That's because `/` is between `-` and `a` in the ascii table. I think
that's quite confusing, and we shouldn#t order that way hence.
As discussed: https://github.com/systemd/systemd/pull/22662#discussion_r831174776
The actual minimum size of the pool across supported kernel versions is
32 bytes. So adjust this minimum.
I've audited every single usage of random_pool_size(), and cannot see
anywhere that this would have any impact at all on anything. We could
actually just not change the constant and everything would be fine, or
we could change it here and that's fine too. From both a functionality
and crypto perspective, it doesn't really seem to make a substantive
difference any which way, so long as the value is ≥32. However, it's
better to be correct and have the function do what it says, so clamp it
to the right minimum.
Lennart Poettering
Yu Watanabe
Frantisek Sumsal
Heiko Becker
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Nishal Kulkarni
Jason A. Donenfeld