Since kernel 5.2 the kernel thankfully returns proper errors when we
write a value out of range to the sysctl. Which however breaks writing
ULONG_MAX to request the maximum value. Hence let's write the new
maximum value instead, LONG_MAX.
/cc @brauner
Fixes: #12803
This is for 6d36464065. It turns out that this is causing more problems than
expected. Let's retroactively introduce naming scheme v241 to conditionalize
this change.
Follow-up for #12792 and 6d36464065. See also
https://bugzilla.suse.com/show_bug.cgi?id=1136600.
$ SYSTEMD_LOG_LEVEL=debug NET_NAMING_SCHEME=v240 build/udevadm test-builtin net_setup_link /sys/class/net/br11
$ SYSTEMD_LOG_LEVEL=debug NET_NAMING_SCHEME=v241 build/udevadm test-builtin net_setup_link /sys/class/net/br11
...
@@ -20,11 +20,13 @@
link_config: could not set ethtool features for br11
Could not set offload features of br11: Operation not permitted
br11: Device has name_assign_type=3
-Using interface naming scheme 'v240'.
+Using interface naming scheme 'v241'.
br11: Policy *keep*: keeping existing userspace name
br11: Device has addr_assign_type=1
-br11: No stable identifying information found
-br11: Could not generate persistent MAC: No data available
+br11: Using "br11" as stable identifying information
+br11: Using generated persistent MAC address
+Could not set Alias=, MACAddress= or MTU= on br11: Operation not permitted
+br11: Could not apply link config, ignoring: Operation not permitted
Unload module index
Unloaded link configuration context.
ID_NET_DRIVER=bridge
This reflect its role better.
(I didn't use …_persistent_name(), because which name is actually used
depends on the policy. So it's better not to make this sound like it returns
*the* persistent name.)
This is in preparation for later changes. Let's change the documentation of
net.naming-scheme= to also say that it applies to MAC addresses. This commit
doesn't actually implement that though.
Previously, when a bridge or bonding interface is in degraded-carrier
state, then we cannot judge the interface has addresses or not.
By using the new states, dbus clients can distinguish such situation.
This reverts commit 18bddeaaf2.
Revert this because it does not take the OpenSSL internal read pointer
into considoration. Resulting in padding in packetdata and therefore
broken SSL connections.
Coverity is unpredictable and, according to a notification I received
yeserday, it will be upgraded on June 17. During the upgrade
it might be offline for 3 days, af far as I understand. Anyway, Travis
stops as soon as a stage fails so it makes sense to put stages that
are likely to fail at the end so that the others have a chance to
do what they are supposed to do.
https://community.synopsys.com/s/topic/0TO2H0000001CN7WAM/coverity-scan-status
includes two travis ci steps:
1) Every pull-request/push all fuzzing targets will do a quick
sanity run on the generated corpus and crashes (via Fuzzit)
2) On a daily basis the fuzzing targets will be compiled (from
master) and will and their respectible fuzzing job on Fuzzit
will be updated to the new binary.
Yu Watanabe