diff options
author | Thomas Haller <thaller@redhat.com> | 2023-04-12 11:18:29 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2023-04-26 17:11:52 +0200 |
commit | e699dff46a7b24be9974bb779fd23b0802ba7a39 (patch) | |
tree | dabfc5e051b3e99ee3ade54345e47edeff5d86a7 | |
parent | 14d429dd17dcc242f13403374a519d3ea17df261 (diff) | |
download | NetworkManager-e699dff46a7b24be9974bb779fd23b0802ba7a39.tar.gz |
device: trigger a recheck to autoconnect when unrealizing ovs-interface
NM_reboot_openvswitch_vlan_configuration_var2 test exposes a race. What
the test does, is to create OVS profiles and repeatedly restart
NetworkManager, checking that those profiles autoconnect and the OVS
configuration gets created.
There is a race, where:
- the OVS interface exists, and an NMDeviceOvsInterface is created
- first ovsdb cleans up old interfaces, sending a json request.
- OVS deletes the interface, and NetworkManager first picks up the
platform signal (there is a race here, usually the ovsdb request
completes first, which will cleanup the NMDeviceOvsInterface in
a different way).
- when the device gets unrealized, we don't schedule a
check-autoactivate, so the device stays down.
See https://bugzilla.redhat.com/show_bug.cgi?id=2152864#c5 for a log
file with more details.
What should instead happen, is to autoactivate the OVS interface, which
then also fully configures the port and bridge interfaces.
Explicitly schedule an autoactivate when unrealizing devices.
Note that there are now several cases, where NetworkManager autoconnects
more eagerly. This even affects some CI tests and user-visible behavior.
But I think relying on "just don't call nm_device_emit_recheck_auto_activate()
to hope that autoconnect doesn't happen is wrong. It must always be
possible to trigger an autoconnect check, and the right thing must
happen. We only don't trigger autoconnect checks *all* the time, because
it would be a waste of CPU resources, but whenever we slightly suspect
that an autoconnect may happen, we must be allowed to trigger a check.
If a device is in a condition where it previously did not autoconnect,
and it also *should* not autoconnect, then we need to fix the code that
evaluates whether an autoconnect may happen (not avoid triggering a
check).
https://bugzilla.redhat.com/show_bug.cgi?id=2152864
Fixes-test: @NM_reboot_openvswitch_vlan_configuration_var2
-rw-r--r-- | src/core/devices/nm-device.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/src/core/devices/nm-device.c b/src/core/devices/nm-device.c index 25b53ee345..c69bb44804 100644 --- a/src/core/devices/nm-device.c +++ b/src/core/devices/nm-device.c @@ -7860,6 +7860,10 @@ nm_device_unrealize(NMDevice *self, gboolean remove_resources, GError **error) /* Garbage-collect unneeded unrealized devices. */ nm_device_recheck_available_connections(self); + /* In case the unrealized device is not going away, it may need to + * autoactivate. Schedule also a check for that. */ + nm_device_emit_recheck_auto_activate(self); + return TRUE; } |