This is only a safety net for runaway programs: it puts a limit on
outgoing messages, i.e. not on resources accessible directly from
outside, but only on resources taken by trusted local code.
When a [SR-IOV] section has no setting, e.g.
```ini
[SR-IOV]
VirtualFunction=0
```
then the kernel previously replied -EINVAL, as we send a rtnl message
with an empty IFLA_VF_INFO container.
See See do_setvfinfo() in net/core/rtnetlink.c of the kernel.
When a [SR-IOV] section that has an unsupported settings by the
interface driver, then previously the kernel partially applied
settings and returned -EOPNOTSUPP. E.f.
```ini
[SR-IOV]
VirtualFunction=0
LinkState=auto
Trust=true
MACAddress=02:01:00:3e:61:34
```
and the interface does not support configuring the link state, then
the MAC address is assigned, but the trust is not applied:
```
enp3s0f0: Failed to configure SR-IOV virtual function 0, ignoring: Operation not supported
vf 0 link/ether 02:01:00:3e:61:34 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
```
To fix such issues, this makes networkd/udevd send each attribute
for VF one-by-one.
Fixes#37257 and #37275.
The configuration can easily fail when the target virtual function
does not exist, and there is nothing networkd can do in such case.
Also, it is overkill to make the physical interface entered to the
failed state in such case. Let's warn but ignore the failure.
These assertions impose an include order between <linux/fs.h> and
"missing_fs.h", specifically <linux/fs.h> can't be included before
"missing_fs.h". This makes automated include refactoring very painful,
so let's get rid of these assertions and instead assume that linux/fs.h
does the right thing.
These glibc headers conflicts with the corresponding linux headers
(<linux/in.h> and <linux/if.h>) and impose an include order (the glibc one
has to be included before any linux header is included). This makes sorting
includes a royal pain so let's define our own versions of these headers using
various linux headers to do all the work and filling in the missing bits
ourselves.
The header requires struct sockaddr declared. So, otherwise, we need to
include sys/socket.h earlier than linux/vm_sockets.h.
Let's make the header includable at any place.
Delegation is enabled for udev so that it can mess around with the
cgroup hierarchy to avoid killing control processes when it calls
cg_kill in on_post() when it goes idle. We don't actually care about
any specific cgroup controllers in udev, so set Delegate= to enable
delegation without delegating any controllers
Follow up for https://github.com/systemd/systemd/pull/22752
This partially reverts 5332be60d3. I expect that
there is no practical difference, but it seems philosophically wrong to use
assert_se(), i.e. for the generation of the code in non-debug builds, just to
suppress a warning. We have _unused_ for that, use it.
I verified that we don't get warnings with clang and -DNDEBUG=1 with this patch.
@DaanDeMeyer Obviously this doesn't fix nearly everything, so gradually
moving things over is probably a smart thing? It seems clang-tidy does
support drop in configs for example:
```
# SPDX-License-Identifier: LGPL-2.1-or-later
---
Checks: '
-*,
bugprone-argument-comment
'
WarningsAsErrors: '*'
```
Its a bit strange that `WarningsAsErrors` isn't propagated, but dropping
this file in src/report/.clang-tiday invokes:
```
[1314/1543][1.5s] /usr/bin/clang-tidy --use-color -extra-arg=-fno-caret-diagnostics -p=/home/jelle/projects/systemd/build -quiet /home/jelle/projec
ts/systemd/src/repart/repart.c
../src/repart/repart.c:4715:41: error: argument name 'pubkey' in comment does not match parameter name 'public' [bugprone-argument-comment,-warning
s-as-errors]
4715 | /* pubkey= */ NULL, /* Turn this one off for the 2nd shard */
| ^
../src/shared/tpm2-util.h:281:108: note: 'public' declared here
281 | int tpm2_calculate_sealing_policy(const Tpm2PCRValue *pcr_values, size_t n_pcr_values, const TPM2B_PUBLIC *public, bool use_pin, const Tpm2
PCRLockPolicy *policy, TPM2B_DIGEST *digest);
| ^
```
So that seems to behave as intended :)
And in some cases I am not sure if switching to the correct argument is
an improvement ie.:
```
../src/bootctl/bootctl-reboot-to-firmware.c:66:51: [38;2;190;132;255m0;1;31merror: argument name 'dispatch_table' in comment does not match paramet
er name 'table' [bugprone-argument-comment,-warnings-as-errors]
66 | r = sd_varlink_dispatch(link, parameters, /* dispatch_table = */ NULL, /* userdata = */ NULL);
| [38;2;190;132;255m0;1;32m ^
../src/systemd/sd-varlink.h:187:98: [38;2;190;132;255m0;1;36mnote: 'table' declared here
187 | int sd_varlink_dispatch(sd_varlink *v, sd_json_variant *parameters, const sd_json_dispatch_field table[], void *userdata);
| [38;2;190;132;255m0;1;32m ^
```
or
```
../src/validatefs/validatefs.c:274:83: [38;2;190;132;255m0;1;31merror: argument name 'ret_len' in comment does not match parameter name 'len' [bugprone-argument-comment,-warnings-as-errors]
274 | (void) blkid_probe_lookup_value(b, "PART_ENTRY_TYPE", &v, /* ret_len= */ NULL);
| [38;2;190;132;255m0;1;32m ^
/usr/include/blkid/blkid.h:455:52: [38;2;190;132;255m0;1;36mnote: 'len' declared here
455 | const char **data, size_t *len)
| [38;2;190;132;255m0;1;32m ^
```
But that's also half a style thing with `len` winning over `ret_len`.
Follow-up for 511619087b.
Notable changes are
- SIGTERM is the highest among others, to make not udevd queue too
many events, as we need to serialize them anyway.
- device monitor has the second highest priority, to make 'remove'
uevents received earlier than IN_IGNORED inotify events. Otherwise,
after IN_IGNORED is received, if there is no queued event,
/run/udev/queue file will be removed by the post-event source of the
inotify event, and 'udevadm settle' or friends may wrongly finish,
even we will soon queue 'remove' uevents for the device.
This change should fix the recent instability of TEST-64-UDEV-STORAGE.
For other changes, see the comments in the code.
Note, it should be safe even if we synthesize no event, e.g. when the
device has been already removed. In such case, the post event after
SIGCHLD will remove the file.
This is mostly a paranoia, but if we failed to create /run/udev/queue
for some reasons on queueing an event, previously we would never create
the file until once the queue became empty. This makes in such case we
try to create the file again when queueing the next event.
RFC 5227 specifies randomized intervals to avoid that a large number of
hosts powered up at the same time send their message simultaneously.
Performing the conflict detection takes a variable time between 4 and 7
seconds from the beginning to the first announcement, as shown by the
following diagram where P indicates a probe and A an announcement:
```
time(s) 0 1 2 3 4 5 6 7 8 9
+---+---+---+---+---+---+---+---+---+
SHORTEST P P P A A
LONGEST P P P A A
```
The host can't use the address until the first announcement is sent. 7
seconds is a very long time on modern computers especially considering
the fact that the round-trip time on current LAN technologies is at most
few milliseconds. Section 2.2 of the RFC addresses this matter and hints
that a future standard will adjust those timeouts; however that standard
doesn't exist yet.
Make the timeout configurable via a new
"IPv4DuplicateAddressDetectionTimeoutSec=" option. The intervals defined
in the RFC are then scaled proportionally so that the duration of the
conflict detection takes at most the given value. Interval happening
after the first announcement are not scaled, as recommended by the RFC.
Also reduce the default value from 7s to 200ms, which is a more suitable
value for today's technology.
The original timeout of 7 seconds is very long for today's networks. Reduce it
to 200ms. Note that this change also affects IPv4 link-local addressing.
Yu Watanabe
Lennart Poettering
Daan De Meyer
Tim Small
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
joo es
David Rheinsberg
Jelle van der Waa
Mike Yuan
Jesper Nilsson
Beniamino Galvani