In order to get a good approximation of latencies when starting
services, timestamp before/after running the test cases and print
the difference. This allows to measure while ignoring the setup/shutdown
time for the test harness.
Given that ERRNO_IS_SECCOMP_FATAL() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_SECCOMP_FATAL() are the
values returned by external libseccomp function seccomp_load() which is
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_SECCOMP_FATAL() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_DEVICE_ABSENT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DEVICE_ABSENT()
are the values returned by external cryptsetup functions
sym_crypt_init_by_name() and sym_crypt_deactivate_by_name() which are
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_DEVICE_ABSENT() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by procfs_get_pid_max() and procfs_get_threads_max() which are
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_PRIVILEGE() invocations to the branches where
the return values are known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_PRIVILEGE() is the value
returned by json_parse_file() which is not expected to return any positive
values, but let's be consistent anyway and move the ERRNO_IS_PRIVILEGE()
invocation to the branch where the return value is known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_PRIVILEGE() is the value
returned by access_fd() which is not expected to return any positive
values, but let's be consistent anyway and move the ERRNO_IS_PRIVILEGE()
invocation to the branch where the return value is known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by set_oom_score_adjust() and set_coredump_filter() which are
not expected to return any positive values, but let's be consistent
anyway and move the ERRNO_IS_PRIVILEGE() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_NOT_SUPPORTED() are the
values returned by btrfs_subvol_make_fd() which is not expected to
return any positive values, but let's be consistent anyway and move
ERRNO_IS_NOT_SUPPORTED() invocations to the branches where
the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_NOT_SUPPORTED() are the
values returned by efi_get_variable_string() and efi_set_variable()
which are not expected to return any positive values, but let's be
consistent anyway and move ERRNO_IS_NOT_SUPPORTED() invocations
to the branches where the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by remount_idmap() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by home_update_quota_auto() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by find_tpm2_auto_data() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the
value returned by varlink_connect_address() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_DISCONNECT() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by dns_transaction_emit_tcp() and dns_transaction_emit_udp()
which are not expected to return any positive values, but let's be
consistent anyway and move the ERRNO_IS_DISCONNECT() invocation
to the branch where the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DISCONNECT() are the
values returned by instance_from_socket(), socket_load_service_unit(),
and service_set_socket_fd() which are not expected to return any
positive values, but let's be consistent anyway and move
ERRNO_IS_DISCONNECT() invocations to the branches where the return
values are known to be negative.
Like we do for root= or so.
Another possible option is adding support of fifth (sixth?) field in
systemd.mount-extra=. But that may be overkill, hence let's do that
later if someone request that.
Fixes fsck part of issue #28541.
Follow-up for 77451f654a.
Now, gateway for routes to DNS or NTP servers should be correctly picked,
hence it is not necessary to adjust the gateway address in
dhcp4_request_route_auto() again.
Also, similar for classless static routes, let's always honor
gateway address specified in (non-classless) static routes.
And if not found, refuse to configure the route.
If a DHCP server provides classless static or static routes, then we
should use the gateway for accessing a node in the range specified in
the route. E.g. if a DHCP server provides the default gateway is
192.168.0.1, and classless static route for 8.0.0.0/8 with gateway
192.168.0.2, then we should access 8.8.8.8 through 192.168.0.2 rather
than 192.168.0.1, but should use 192.168.0.1 for 9.9.9.9.
Fixes#28358.
Previously, we use the first router address, and if it is null, we
ignore the address. Now, we use the first non-null address. That is, if
the first router address is null, but the second is not, then we use the
second one.
That should not cause functional change in most cases, except for the case
when a DHCP server provides such spurious reply.
This is mostly for refactoring and preparation for later commits.
Luca Boccassi
Dmitry V. Levin
Daan De Meyer
Frantisek Sumsal
Susant Sahani
Zbigniew Jędrzejewski-Szmek
Yu Watanabe