Don't progress to the IP ready state until all objects are committed
to platform. Note that l3cfg has a 20 seconds timeout after which
unavailable objects are considered "definitely unavailable" and are
removed from the list.
Fixes-test: @ipv6_routes_with_src
https://bugzilla.redhat.com/show_bug.cgi?id=2043133
l3cfg has a "temp_not_available" list of objects that couldn't be
added to platform, but can be added once some preconditions become
true (for example, a IPv6 route with a "src" attribute requires a
non-tentative src address to be present).
Retry to commit those objects once all addresses have completed
ACD/DAD.
nm_l3_config_data_get_nameservers() returns a pointer to "struct in6_addr". Not
a pointer to pointers.
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:389
#1 0x00007f8060dd9109 in memcpy (__len=<optimized out>, __src=0xfd, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:29
#2 g_array_append_vals (len=1, data=0xfd, farray=0x55dd69332130) at ../glib/garray.c:522
#3 g_array_append_vals (farray=0x55dd69332130, data=0xfd, len=1) at ../glib/garray.c:509
#4 0x000055dd68d2a27d in _garray_inaddr_add (p_arr=<optimized out>, addr_family=<optimized out>, addr=0xfd) at src/core/nm-l3-config-data.c:295
#5 0x000055dd68ef6510 in nm_l3_config_data_add_nameserver (nameserver=<optimized out>, addr_family=10, self=0x55dd6949f900) at src/core/nm-l3-config-data.c:1442
#6 nm_device_copy_ip6_dns_config (self=0x55dd693c4420, from_device=<optimized out>) at src/core/devices/nm-device.c:10468
#7 0x00007f8060f28aba in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7fffed43d610, instance=0x55dd693c4420, return_value=0x0, closure=0x55dd693cdb10)
at ../gobject/gclosure.c:893
#8 g_signal_emit_valist (instance=0x55dd693c4420, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffed43d610) at ../gobject/gsignal.c:3406
#9 0x00007f8060f28c03 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3553
#10 0x000055dd68efd1fb in _dev_ipac6_start (self=0x55dd693c4420) at src/core/devices/nm-device.c:11348
#11 0x000055dd68efd698 in _dev_ipac6_start_continue (self=0x55dd693c4420) at src/core/devices/nm-device.c:11373
#12 _dev_ipll6_set_llstate (self=0x55dd693c4420, llstate=<optimized out>, lladdr=<optimized out>) at src/core/devices/nm-device.c:10576
#13 0x000055dd68e7915e in _emit_changed_on_idle_cb (user_data=user_data@entry=0x55dd6941ca50) at src/core/nm-l3-ipv6ll.c:221
#14 0x00007f8060e0639b in g_idle_dispatch (source=0x55dd693eea30, callback=0x55dd68e78fd0 <_emit_changed_on_idle_cb>, user_data=0x55dd6941ca50) at ../glib/gmain.c:5897
#15 0x00007f8060e0a05f in g_main_dispatch (context=0x55dd6922c800) at ../glib/gmain.c:3381
#16 g_main_context_dispatch (context=0x55dd6922c800) at ../glib/gmain.c:4099
#17 0x00007f8060e5f2a8 in g_main_context_iterate.constprop.0 (context=0x55dd6922c800, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4175
#18 0x00007f8060e09773 in g_main_loop_run (loop=0x55dd69211010) at ../glib/gmain.c:4373
#19 0x000055dd68d09c7b in main (argc=<optimized out>, argv=<optimized out>) at src/core/main.c:509
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
The general idea is that when we have entries tracked by the
route-manager, that we can mark them all as dirty. Then, calling the
"track" function will reset the dirty flag. Finally, there is a method
to delete all dirty entries.
As we can lookup an entry with O(1) (using dictionaries), we can
sync the list of tracked objects with O(n). We just need to track
all the ones we care about, and then delete those that were not touched
(that is, are still dirty).
Previously, we had to explicitly mark all entries as dirty. We can do
better. Just let nmp_route_manager_untrack_all() mark the survivors as
dirty right away. This way, we can save iterating the list once.
It also makes sense because the only purpose of the dirty flag is to
aid this prune mechanism with track/untrack-all. So, untrack-all can
just help out, and leave the remaining entries dirty, so that the next
track does the right thing.
Routes of type blackhole, unreachable, prohibit don't have an
ifindex/device. They are thus in many ways similar to routing rules,
as they are global. We need a mediator to keep track which routes
to configure.
This will be very similar to what NMPRulesManager already does for
routing rules. Rename the API, so that it also can be used for routes.
Renaming the file will be done next, so that git's rename detection
doesn't get too confused.
Names in header files should have an "nm" prefix. We do that pretty
consistently. Fix the offenders RfKillState and RfKillType.
Also, rename the RfKillState enums to follow the type name. For example,
NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED.
Also, when we camel-case a typedef (NMRfKillState) we would want that
the lower-case names use underscore between the words. So it should be
`nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution
here is to also rename "RfKill" to "Rfkill". That make is consistent
with the spelling of the existing `NMRfkillManager` type and the
`nm-rfkill-manager.h` file.
GObject Properties are flexible and powerful. In practice, NMDevicePrivate.rfkill_type
was only set once via the construct-only property NM_DEVICE_RFKILL_TYPE.
Which in turn was always set to a well-known value, only depending on the device
type.
We don't need this flexibility. The rfkill-type only depends on the
device type and doesn't change. Replace the property by a field in
NMDeviceClass.
For one, construct properties have an overhead, that the property setter is
called whenever we construct a NMDevice. But the real reason for this
change, is that a property give a notion as this could change during the
lifetime of a NMDevice (which it in fact did not, being construct-only).
Or that the type depends on something more complex, when instead it only
depends on the device type. A non-mutated class property is simpler,
because it's clear that it does not depend on the device instance,
only on the type/class.
Also, `git grep -w rfkill_type` now nicely shows the (few) references to
this variable and its easier to understand.
We don't run glib-mkenums for certain sources like "core" and
"libnm-glib-aux".
These annotations have no effect. Drop them.
They also mess with the automated formatting.
The metered status can depend on the DHCP lease, as we accept the
ANDROID_METERED vendor option. That means, on a DHCP update we need
to re-evaluate the metered flag.
This fixes a potential race, where IPv6 might succeed first and
activation completes (with GUESS_NO metered flag). A subsequent
DHCPv4 update requires to re-evaluate that decision.
Fixes-test: @connection_metered_guess_yes
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1080
When the NM_UNMANAGED_PLATFORM_INIT flag is cleared last in
device_link_changed(), a recheck-assume is scheduled and then the
device goes immediately to UNAVAILABLE. During the state transition,
addresses and routes are removed from the interface. Then,
recheck-assume finds that the device can be assumed but it's too late
since the device was already deconfigured.
This is a problem as the whole point of assuming a device is to
activate a connection while leaving the device untouched.
In the NMCI "dracut_NM_vlan_over_bridge and dracut_NM_vlan_over_bond"
test, NM in real root tries to assume a vlan device that was activated
in initrd. When the interface gets deconfigured in UNAVAILABLE, the
connection to the NFS server breaks and the rootfs becomes
inaccessible.
The fix to this problem is to delay state transitions in
device_link_changed() to a idle handler, so that recheck-assume can
run before.
Fixes-test: @dracut_NM_vlan_over_bridge
Fixes-test: @dracut_NM_vlan_over_bond
https://bugzilla.redhat.com/show_bug.cgi?id=2047302
nm_device_set_unmanaged_by_user_settings() does nothing when the
device is unmanaged by platform-init. Remove the if branch to make
this more explicit.
Now that higher priorities numbers really mean more important,
it seems that the VPN configuration should be rather important.
Bump the number, also in relation to NMDevice's L3ConfigDataType.
It might not matter too much, because usually the VPN tunnel device does
not have NDevice to add other l3cds and those from VPN might be alone.
Except, maybe with routing VPN (libreswan) that is different. Dunno.
NM_L3CFG_CONFIG_PRIORITY_IPV6LL and L3_CONFIG_DATA_TYPE_LL_6 are
somewhat related. They probably should be numerically identical.
Now, L3_CONFIG_DATA_TYPE_LL_6 cannot be zero (because
L3_CONFIG_DATA_TYPE_LL_4 is zero and L3ConfigDataType values must be
distinct). Therefore, also bump NM_L3CFG_CONFIG_PRIORITY_IPV6LL to 1.
Of course, NM_L3CFG_CONFIG_PRIORITY_IPV6LL is not obviously more important
than NM_L3CFG_CONFIG_PRIORITY_IPV4LL. But to be consistent with
L3_CONFIG_DATA_TYPE_LL_6 is probably more important here.
There was a disagreement whether higher priority numbers mean more/less
important. NMDevice and callers of nm_l3cfg_add_config() assumed that
higher numbers are more important, while _l3_config_datas_get_sorted_cmp()
did the inverse.
There is no obvious right or wrong. We only need to agree. It seems
slightly more sensible to keep the caller's interpretation.
This commit does not seem correct. The enum was moved with the declared
intent to make manual IP configuration preferred. But the code comment
in L3ConfigDataType states that higher numbers are more important.
Also, all the other values are intentionally ordered so that more
important method have higher numbers. For example, LL_4 < DHCP_4 < SHARED_4 <
DEV_4 (in increasing priority). While it's often not clear whether to
prefer one method over the other, or what the actual effect of (LL_4 < DHCP_4)
is, the numbers were chosen intentionally.
Only moving MANUALIP first, counters the relative order of the other values.
If there is the problem, that the code comment is wrong (and lower
numbers mean more important), then we would have to reverse all
enum values.
The real problem is that NML3Cfg's _l3_config_datas_get_sorted_cmp()
has the wrong order/understanding. So the real fix is there and will
be done next. That is, unless we would agree that _l3_config_datas_get_sorted_cmp()
is in the right, and prefer lower numbers -- in which case all values had to be
reversed.
This reverts commit af1903fe3f.
When NetworkManager shuts down, it is not done properly. We cannot
ensure that all pending async operations are cancelled and therefore
there are possible device leaks. This means that not all the devices
will be disposed and finalized because a different component is handling
a reference to it.
Since the l3cfg refactor, this is affecting to ovs ports. When shutting
down sometimes there are ovs-interface or ovs-port devices that are not
being cleared correctly. When starting NetworkManager back, these
devices are not going to be created again because they already exist and
the existing compatible connections will be instruct to use the device.
But currently, ovsdb is only unrealizing a device after removal if the
state is UNMANAGED. This is wrong, because it will left an inconsistent
state in NetworkManager and the ovs-port/ovs-interface connection won't
be activated.
The interfaces removed by ovsdb must be unrealized if they are on
UNAVAILABLE state.
https://bugzilla.redhat.com/show_bug.cgi?id=2029937
The properties NM_DEVICE_MODEM_CAPABILITIES and
NM_DEVICE_MODEM_CURRENT_CAPABILITIES are uint, with a range from zero to
G_MAXUINT32.
nm_modem_get_capabilities() passes the "untrusted" flags from
ModemManager. Ensure that they fit into 32 bit, and don't cause an
assertion failure due to the range check.
Yes, in practice, on all platforms where we build (known to me), guint
is always the same as guint32. So this has little effect.
Also, cast to guint. Previously, this was just a C enum
NMDeviceModemCapabilities, which theoretically has implementation
defined sizes. Yes, in practice, they too are of size guint, and this
was not an actual bug. But be specific about converting between
different integer types.
Macros should (where possible and sensible) behave function-like.
That means for example, that they evaluate arguments only once, and
use parentheses around code that expands, so that unexpected uses
work correctly. The parentheses was missing.
Instead, just use the NM_FLAGS_ANY() macro which gets this right.
For IPv6 the lease doesn't necessarily have an address. If the address
is missing or the DHCP client doesn't implement accept(), we don't
need to wait for the address in platform.
From https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1066#note_1233210 :
0 0x00007ffff760f88c in __pthread_kill_implementation () at /lib64/libc.so.6
1 0x00007ffff75c26a6 in raise () at /lib64/libc.so.6
2 0x00007ffff75ac7d3 in abort () at /lib64/libc.so.6
3 0x00007ffff77c5d4c in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, message=<optimized out>)
at ../glib/gtestutils.c:3223
4 0x00007ffff782645f in g_assertion_message_expr
(domain=domain@entry=0x5555559e7c96 "nm", file=file@entry=0x5555559deac0 "src/core/dhcp/nm-dhcp-client.c", line=line@entry=609, func=func@entry=0x5555559e0090 <__func__.31> "l3_cfg_notify_cb", expr=expr@entry=0x5555559df5cf "lease_address") at ../glib/gtestutils.c:3249
5 0x00005555558b2866 in l3_cfg_notify_cb (l3cfg=0x555555c29790, notify_data=<optimized out>, self=0x555555e9a1b0) at src/core/dhcp/nm-dhcp-client.c:609
9 0x00007ffff791abe3 in <emit signal ??? on instance ???> (instance=instance@entry=0x555555c29790, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
6 0x00007ffff78fcc7f in g_closure_invoke (closure=0x555555ca3900, return_value=0x0, n_param_values=2, param_values=0x7fffffffd420, invocation_hint=0x7fffffffd3a0)
at ../gobject/gclosure.c:830
7 0x00007ffff7919106 in signal_emit_unlocked_R
(node=node@entry=0x555555bbadc0, detail=detail@entry=0, instance=instance@entry=0x555555c29790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd420) at ../gobject/gsignal.c:3742
8 0x00007ffff791a9ca in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd5f0)
at ../gobject/gsignal.c:3497
10 0x000055555564c8a6 in _nm_l3cfg_emit_signal_notify (self=self@entry=0x555555c29790, notify_data=notify_data@entry=0x7fffffffdf30) at src/core/nm-l3cfg.c:576
11 0x000055555564ce77 in _nm_l3cfg_emit_signal_notify_simple (self=self@entry=0x555555c29790, notify_type=notify_type@entry=NM_L3_CONFIG_NOTIFY_TYPE_POST_COMMIT)
at src/core/nm-l3cfg.c:585
12 0x0000555555656082 in _l3_commit (self=self@entry=0x555555c29790, commit_type=NM_L3_CFG_COMMIT_TYPE_UPDATE, commit_type@entry=NM_L3_CFG_COMMIT_TYPE_AUTO, is_idle=is_idle@entry=1)
at src/core/nm-l3cfg.c:4201
13 0x0000555555656189 in _l3_commit_on_idle_cb (user_data=user_data@entry=0x555555c29790) at src/core/nm-l3cfg.c:2961
14 0x00007ffff77f847b in g_idle_dispatch (source=0x555555d65680, callback=0x55555565612c <_l3_commit_on_idle_cb>, user_data=0x555555c29790) at ../glib/gmain.c:5897
15 0x00007ffff77fc130 in g_main_dispatch (context=0x555555aa5020) at ../glib/gmain.c:3381
16 g_main_context_dispatch (context=0x555555aa5020) at ../glib/gmain.c:4099
17 0x00007ffff7851208 in g_main_context_iterate.constprop.0 (context=0x555555aa5020, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4175
18 0x00007ffff77fb853 in g_main_loop_run (loop=0x555555aa5970) at ../glib/gmain.c:4373
19 0x0000555555593c56 in main (argc=<optimized out>, argv=<optimized out>) at src/core/main.c:509
Fixes: e1648d0665 ('core: commit l3cd asynchronously on DHCP bound event')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1074
When a lease is obtained, currently NMDevice performs a synchronous
commit of IP configuration and then accepts the lease.
Instead, let NMDevice only schedule a async commit; when the DHCP
client notices that the new address was committed it will
automatically accept it and emit a new signal so that the device can
succeed the activation.
Sync commits should be avoided because a commit does of things which
are outside the control of the caller (see the comment in
nm_device_l3cfg_commit()). Furthermore, when there are many pending
activations, async commits seem to help in reducing the CPU usage.
While making the commit async, also move the responsibility of the
accept() to NMDhcpClient.
Currently, ip4 new config signal is being emitted twice, due
to the lack of a barrier to a possible situation. This
commit includes this.
This fixes a crash on NMCI tests due to an assertion failure,
now it will not go ahead in the function anymore if it is under the
undesired conditions.
The backtrace of the crashes can be found at
https://bugzilla.redhat.com/show_bug.cgi?id=2028385
If the connection has wfd_ies set, we want to ensure that a WFD
connection is being established so we want to check that the target peer
also supports WFD. For now this in the IWD backend only.
However, WFD peers will send us their WFD IEs in their Probe Responses
only if our own Probe Request contained a WFD IE, or at least that's
when the spec mandates that they include the WFD IE. This implies that
the discovery phase (NM.Device.WifiP2P.StartFind(options) / .StopFind())
needs to know the value of the local WFD IE and include it in the Probe
Requests, which existing clients (gnome-network-displays) doesn't do and
in fact can't do because there's no API for the client to pass the WFD
IE -- that is easy to add in the options parameter though (a
dictionary).
The current situation is that with the wpa_supplicant backend we'll
sometimes see the WFD IE (when the peer is discovered from a Probe
Request that it has sent, rather than from a Probe Response) and
sometimes not, while with the IWD backend we'll never see the WFD
information because IWD assumes that the client (NM) is not interested
in seeing it if it hasn't registered the local WFD information before
starting discovery.
So, for compatibility with this existing situation and with the
wpa_supplicant backend, ignore whether the peer is a WFD peer except in
the PREPARE stage. In PREPARE, if we have a peer compatible with the
connection being activated -- except for the WFD information -- force a
new discovery, this time passing the WFD information from the
NMSettingConnection's wfd_ies, and only progress to CONFIG if the target
peer is re-discovered as a WFD peer within 10 seconds.
We don't actually check the contents of the WFD IEs to match, e.g. we
don't check the sink/source/dual role compatibility between our and the
peer's properties, but IWD will do some of these checks later during
activation.
Similarly as with wpa_supplicant, create NMDeviceIwdP2P objects for P2P
devices based on data from IWD -- not in NMWifiFactory::create_device
because that is only triggered for system netdevs and a P2P-Device
virtual interface has no netdev. Unlike NMDeviceWifiP2P,
NMDeviceIwdP2P's iface property is a unique string that likely doesn't
match any system interface name -- in theory there doesn't need to be
any related netdev on the system (such as an Infrastructure-mode
interface) before a P2P-Device is added.
[thaller@redhat.com: modified original patch]
Since the NM D-Bus API talks to the client using raw WFD IE bytes and
IWD's API wants/provides some of the actual values from the WFD IE
instead (e.g. boolean Source and Sink properties), we need to be able to
parse and build the WFD IE from those property values to do the
translation, add utilities for this. Use one of them to build the WFD IE
property on NMWifiP2PPeer objects.
[thaller@redhat.com: modify original patch to use
nm_g_variant_unref() and add missing #define]
In NMWifiFactory, move the check that prevents NMDevice's from being
created for interfaces in Monitor and other modes, out of the
wpa_supplicant-specific block so that it applies to both IWD and
wpa_supplicant. This check allows P2P device creation to work
differently that Infrastructure, Ad-Hoc and AP modes so it's needed for
P2P support in the IWD backend.
While there change the check to list the modes that are accepted rather
than rely on some of the modes (Monitor, P2P-{Device,Client,GO}) being
bunched together as _NM_802_11_MODE_UNKNOWN.
The interface name has changed in 2019 but the WSC interface has
never been used by NM. Update #define NM_IWD_WSC_INTERFACE in
nm-iwd-manager.h accordingly.
If the ovs interface goes away, the ifindex gets zeroed out and l3cfg is
cleaned. We can't follow up with IP configuration. Bad things happen if
we try to:
#0 0x00007f769734c895 in _g_log_abort (breakpoint=1) at gmessages.c:580
#1 0x00007f769734db98 in g_logv (log_domain=0x55b2472d8840 "nm",
log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>,
args=args@entry=0x7fff4041b9d0) at gmessages.c:1391
#2 0x00007f769734dd63 in g_log (log_domain=log_domain@entry=0x55b2472d8840 "nm",
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7f769739a620 "%s: assertion '%s' failed") at gmessages.c:1432
#3 0x00007f769734e59d in g_return_if_fail_warning
(log_domain=log_domain@entry=0x55b2472d8840 "nm",
pretty_function=pretty_function@entry=0x55b2472d5fe0 <__func__.39677> "nm_lndp_ndisc_new",
expression=expression@entry=0x55b2472d5fa3 "NM_IS_L3CFG(config->l3cfg)")
at gmessages.c:2809
#4 0x000055b2471ce3fa in nm_lndp_ndisc_new (config=config@entry=0x7fff4041bb30)
at src/core/ndisc/nm-lndp-ndisc.c:680
#5 0x000055b247123b32 in _dev_ipac6_start (self=self@entry=0x55b248078360 [NMDeviceOvsInterface])
at src/core/devices/nm-device.c:11287
#6 0x000055b2471232f8 in _dev_ipac6_start_continue (self=0x55b248078360 [NMDeviceOvsInterface])
at src/core/devices/nm-device.c:11338
#7 0x000055b2471232f8 in _dev_ipll6_set_llstate (self=0x55b248078360 [NMDeviceOvsInterface],
llstate=<optimized out>, lladdr=<optimized out>) at src/core/devices/nm-device.c:10541
#8 0x000055b2471c9e8b in _emit_changed_on_idle_cb (user_data=user_data@entry=0x55b24807bdd0)
at src/core/nm-l3-ipv6ll.c:221
#9 0x00007f769734327b in g_idle_dispatch (source=0x55b248119200,
callback=0x55b2471c9ce0 <_emit_changed_on_idle_cb>,
user_data=0x55b24807bdd0) at gmain.c:5579
#10 0x00007f769734695d in g_main_dispatch (context=0x55b247f56bc0) at gmain.c:3193
#11 0x00007f769734695d in g_main_context_dispatch (context=context@entry=0x55b247f56bc0)
at gmain.c:3873
#12 0x00007f7697346d18 in g_main_context_iterate (context=0x55b247f56bc0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
#13 0x00007f7697347042 in g_main_loop_run (loop=0x55b247f320f0) at gmain.c:4142
#14 0x000055b246f26b64 in main (argc=<optimized out>,
argv=<optimized out>) at src/core/main.c:511
https://bugzilla.redhat.com/show_bug.cgi?id=2012934https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1044
Fixes-test: @ovs_cloned_mac_set_on_iface
If the ovs interface goes away, the ifindex gets zeroed out and l3cfg is
cleaned. Avoid starting ac6 in that case -- add checks similar to what
we do for ll6.
Bad things happen otherwise:
#0 0x00007f769734c895 in _g_log_abort (breakpoint=1) at gmessages.c:580
#1 0x00007f769734db98 in g_logv (log_domain=0x55b2472d8840 "nm",
log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>,
args=args@entry=0x7fff4041b9d0) at gmessages.c:1391
#2 0x00007f769734dd63 in g_log (log_domain=log_domain@entry=0x55b2472d8840 "nm",
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7f769739a620 "%s: assertion '%s' failed") at gmessages.c:1432
#3 0x00007f769734e59d in g_return_if_fail_warning
(log_domain=log_domain@entry=0x55b2472d8840 "nm",
pretty_function=pretty_function@entry=0x55b2472d5fe0 <__func__.39677> "nm_lndp_ndisc_new",
expression=expression@entry=0x55b2472d5fa3 "NM_IS_L3CFG(config->l3cfg)")
at gmessages.c:2809
#4 0x000055b2471ce3fa in nm_lndp_ndisc_new (config=config@entry=0x7fff4041bb30)
at src/core/ndisc/nm-lndp-ndisc.c:680
#5 0x000055b247123b32 in _dev_ipac6_start (self=self@entry=0x55b248078360 [NMDeviceOvsInterface])
at src/core/devices/nm-device.c:11287
#6 0x000055b2471232f8 in _dev_ipac6_start_continue (self=0x55b248078360 [NMDeviceOvsInterface])
at src/core/devices/nm-device.c:11338
#7 0x000055b2471232f8 in _dev_ipll6_set_llstate (self=0x55b248078360 [NMDeviceOvsInterface],
llstate=<optimized out>, lladdr=<optimized out>) at src/core/devices/nm-device.c:10541
#8 0x000055b2471c9e8b in _emit_changed_on_idle_cb (user_data=user_data@entry=0x55b24807bdd0)
at src/core/nm-l3-ipv6ll.c:221
#9 0x00007f769734327b in g_idle_dispatch (source=0x55b248119200,
callback=0x55b2471c9ce0 <_emit_changed_on_idle_cb>,
user_data=0x55b24807bdd0) at gmain.c:5579
#10 0x00007f769734695d in g_main_dispatch (context=0x55b247f56bc0) at gmain.c:3193
#11 0x00007f769734695d in g_main_context_dispatch (context=context@entry=0x55b247f56bc0)
at gmain.c:3873
#12 0x00007f7697346d18 in g_main_context_iterate (context=0x55b247f56bc0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
#13 0x00007f7697347042 in g_main_loop_run (loop=0x55b247f320f0) at gmain.c:4142
#14 0x000055b246f26b64 in main (argc=<optimized out>,
argv=<optimized out>) at src/core/main.c:511
We need to first free "priv->bzobjs", which then will unlink all bzobjs
from the lists. The assert needs to go after.
https://bugzilla.redhat.com/show_bug.cgi?id=2028427
Fixes: 4154d9618c ('bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data')
NMSettingOvsDpdk does not have a verify() implementation that would prevent
the devargs property from being NULL. We must thus anticipate and handle
a NULL value.
Fixes: ae4152120a ('ovs/ovsdb: add support for setting dpdk devargs option')
