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')
(cherry picked from commit d6395f7ee7)
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')
(cherry picked from commit d5f917e702)
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
This is the style we have ever since. Spell it out. With the difference
that now single line statements may have braces.
Recently we were already sloppy about allowing curly braces for single line
statements. Maybe there was a point in that. Imagine you start with:
if (condition)
call(some, parameter);
Afterwards you change the code so that the line becomes too long and
clang-format wraps the line (requiring you to add braces):
if (condition) {
call(some,
call_another_function(hey));
}
The problem now is that this diff is larger than it would have been, if
you added curly braces from the start. Also, it means you have to go
back and forth to add/remove these braces, as clang-format reformats the
code.
Also, if you have if-else-if blocks, then mixing multi line statements
with single line statements is also cumbersome, because when something
needs to change, the diff is may be larger (and the change more
cumbersome).
So it might be convenient to just always add the braces, and the
documented style now allows for that.
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')
It's not clear how this could happen, but it did:
#0 _g_log_abort (breakpoint=1) at gmessages.c:580
#0 0x00007f4e782c5895 in _g_log_abort (breakpoint=1) at gmessages.c:580
#1 0x00007f4e782c6b98 in g_logv (log_domain=0x558436ef1520 "nm", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffd5b20b0c0) at gmessages.c:1391
#2 0x00007f4e782c6d63 in g_log (log_domain=log_domain@entry=0x558436ef1520 "nm", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7f4e78313620 "%s: assertion '%s' failed") at gmessages.c:1432
#3 0x00007f4e782c759d in g_return_if_fail_warning (log_domain=log_domain@entry=0x558436ef1520 "nm", pretty_function=pretty_function@entry=0x558436e49820 <__func__.43636> "nm_ip6_config_reset_addresses_ndisc", expression=expression@entry=0x558436e48b00 "priv->ifindex > 0") at gmessages.c:2809
#4 0x0000558436bc47ca in nm_ip6_config_reset_addresses_ndisc (self=0x5584385cc190 [NMIP6Config], addresses=0x5584385952a0, addresses_n=1, plen=plen@entry=64 '@', ifa_flags=ifa_flags@entry=768) at src/core/nm-ip6-config.c:1468
#5 0x0000558436d32e50 in ndisc_config_changed (ndisc=<optimized out>, rdata=0x55843856e4d0, changed_int=159, self=0x5584385c00f0 [NMDeviceOvsInterface]) at src/core/devices/nm-device.c:10838
#6 0x00007f4e7323b09e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#7 0x00007f4e7323aa4f in ffi_call (cif=cif@entry=0x7ffd5b20b550, fn=fn@entry=0x558436d32a30 <ndisc_config_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7ffd5b20b460) at ../src/x86/ffi64.c:525
#8 0x00007f4e787a0386 in g_cclosure_marshal_generic_va (closure=<optimized out>, return_value=<optimized out>, instance=<optimized out>, args_list=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=<optimized out>) at gclosure.c:1604
#9 0x00007f4e7879f616 in _g_closure_invoke_va (closure=0x55843850b200, return_value=0x0, instance=0x55843856e5d0, args=0x7ffd5b20b800, n_params=2, param_types=0x558438495e50) at gclosure.c:867
#10 0x00007f4e787bba9c in g_signal_emit_valist (instance=0x55843856e5d0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffd5b20b800) at gsignal.c:3301
#11 0x00007f4e787bc093 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3448
#12 0x0000558436ddf04b in check_timestamps (ndisc=ndisc@entry=0x55843856e5d0 [NMLndpNDisc], now_msec=now_msec@entry=15132, changed=changed@entry=(NM_NDISC_CONFIG_DHCP_LEVEL | NM_NDISC_CONFIG_GATEWAYS | NM_NDISC_CONFIG_ADDRESSES | NM_NDISC_CONFIG_ROUTES | NM_NDISC_CONFIG_DNS_SERVERS | NM_NDISC_CONFIG_MTU)) at src/core/ndisc/nm-ndisc.c:1539
#13 0x0000558436de08d0 in nm_ndisc_ra_received (ndisc=ndisc@entry=0x55843856e5d0 [NMLndpNDisc], now_msec=now_msec@entry=15132, changed=changed@entry=(NM_NDISC_CONFIG_DHCP_LEVEL | NM_NDISC_CONFIG_GATEWAYS | NM_NDISC_CONFIG_ADDRESSES | NM_NDISC_CONFIG_ROUTES | NM_NDISC_CONFIG_DNS_SERVERS | NM_NDISC_CONFIG_MTU)) at src/core/ndisc/nm-ndisc.c:1556
#14 0x0000558436dd8d50 in receive_ra (ndp=<optimized out>, msg=0x5584385e77c0, user_data=<optimized out>) at src/core/ndisc/nm-lndp-ndisc.c:333
#15 0x00007f4e794718a3 in ndp_call_handlers (msg=0x5584385e77c0, ndp=0x5584384db840) at libndp.c:1993
#16 0x00007f4e794718a3 in ndp_sock_recv (ndp=0x5584384db840) at libndp.c:1871
#17 0x00007f4e794718a3 in ndp_call_eventfd_handler (ndp=ndp@entry=0x5584384db840) at libndp.c:2097
#18 0x00007f4e7947199f in ndp_callall_eventfd_handler (ndp=0x5584384db840) at libndp.c:2126
#19 0x0000558436dda229 in event_ready (fd=<optimized out>, condition=<optimized out>, user_data=<optimized out>) at src/core/ndisc/nm-lndp-ndisc.c:588
#20 0x00007f4e782bf95d in g_main_dispatch (context=0x558438409a40) at gmain.c:3193
#21 0x00007f4e782bf95d in g_main_context_dispatch (context=context@entry=0x558438409a40) at gmain.c:3873
#22 0x00007f4e782bfd18 in g_main_context_iterate (context=0x558438409a40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
#23 0x00007f4e782c0042 in g_main_loop_run (loop=0x5584383e5150) at gmain.c:4142
Above is a stack trace of commit af00e39dd2 ('libnm: add NMIPAddress
and NMIPRoute dups backported symbols from 1.30.8').
As workaround, ignore the ndisc signal, if we currently don't have an ifindex.
Also, recreate the NMIP6Config instances, if the ifindex doesn't match
(or we don't have one).
This workaround is probably good enough for the stable branch, as the
code on main (1.35+) was heavily reworked and the fix does not apply
there.
https://bugzilla.redhat.com/show_bug.cgi?id=2013266#c1https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1058
We get the hostname via D-Bus (from hostnamed) or read it from file.
In the latter case, it is not ensured that it's valid UTF-8.
Non-UTF-8 "strings" are bad, because we might try to expose them
on D-Bus, log them or other bad things.
Sanitize the string by using backslash escaping. Maybe we should
outright reject such binary nonsense, but it's not done here,
for no strong reasons.
We have at least static and transient hostnames. Let's be clear which
one we are talking about.
Note that also NM_SETTINGS_HOSTNAME gets renamed to
NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer.
The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing
property for the "Hostname" D-Bus property for the NMDBusObject glue.
So, while the new name makes more sense to me, it's now also
inconsistent with it's primary use (the D-Bus property). Still...
There are very few places left where we would accept tabs in a source
file. Warn about that, even if it might cause some false positives.
I think this line was commented out due to a mistake.
When the device gets realized, similar to the situation that the device
is unmanaged by platform-init, if the device is still unmanaged by
parent and we clear the assume state. Then, when the device becomes
managed, NM is not able to properly assume the device using the UUID.
Therefore, we should not clear the assume state if the device has only
the NM_UNMANAGED_PLATFORM_INIT or the NM_UNMANAGED_PARENT flag set
in the unmanaged flags.
The previous commit 3c4450aa4d ('core: don't reset assume state too
early') did something similar for NM_UNMANAGED_PLATFORM_INIT flag only.
(cherry picked from commit 87674740d8)
We avoid printing pointer values directly, instead we usually call
NM_HASH_OBFUSCATE_PTR(). This hashes the pointers with a random seed
so they are not directly visible.
That obviously makes it harder to debug. Add an environment variable
to disable that.
$ NM_OBFUSCATE_PTR=0 LIBNM_CLIENT_DEBUG=trace,stdout nmcli
Note that this flag is only honored in debug builds (WITH_MORE_ASSERTS>0).
The "Ignore-Backport" tag can be used to mark a commit that should not
be backported. Similar to the "cherry picked from" line, which indicates
that the patch was backported.
Anyway, this didn't work correctly, because we first pre-filter the
commits we search (as a performance optimization) by using `git-log` to
get a subset of the commits we want to investigate.
So if you had a commit with an "Ignore-Backport" tag, but without "cherry
picked from" line, then it wasn't found.
Fix that.
Older branches, like "nm-1-32" will always be formatted with a
different, older clang-format version. Luckily we also have on "nm-1-32"
branch the "nm-code-format-container.sh" script, so we can still
reformat the sources using the container.
However, as the name of the container was always "nm-code-format",
we would have to re-generate the container when we switch between
branches. As the container really only depends on the Fedora version
(as the clang-format version is tied to the corresponding Fedora
version), let's include the Fedora version in the name of the container.
$ nmcli connection modify dummy1 ethtool.feature-rx a
(process:3077356): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: 'a' is not valid; use 'on', 'off', or 'ignore'
Error: failed to modify ethtool.feature-rx: 'a' is not valid; use [true, yes, on], [false, no, off] or [unknown].
Fixes: e5b46aa38a ('cli: use nmc_string_to_ternary() to parse ternary in _set_fcn_ethtool()')
(cherry picked from commit 25e705c361)
$ nmcli connection modify dummy1 ethtool.feature-rx a
(process:3077356): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: 'a' is not valid; use 'on', 'off', or 'ignore'
Error: failed to modify ethtool.feature-rx: 'a' is not valid; use [true, yes, on], [false, no, off] or [unknown].
Fixes: e5b46aa38a ('cli: use nmc_string_to_ternary() to parse ternary in _set_fcn_ethtool()')
When the device gets realized, similar to the situation that the device
is unmanaged by platform-init, if the device is still unmanaged by
parent and we clear the assume state. Then, when the device becomes
managed, NM is not able to properly assume the device using the UUID.
Therefore, we should not clear the assume state if the device has only
the NM_UNMANAGED_PLATFORM_INIT or the NM_UNMANAGED_PARENT flag set
in the unmanaged flags.
The previous commit 3c4450aa4d ('core: don't reset assume state too
early') did something similar for NM_UNMANAGED_PLATFORM_INIT flag only.
Routing daemons can add a large amount of routes to the
system. Currently NM receives netlink notifications for all those
routes and exposes them on D-Bus. With many routes, the daemon becomes
increasingly slow and uses a lot of memory.
The rtm_protocol field of the route indicates the source of the
route. From /usr/include/linux/rtnetlink.h, the allowed values are:
#define RTPROT_UNSPEC 0
#define RTPROT_REDIRECT 1 /* Route installed by ICMP redirects;
not used by current IPv4 */
#define RTPROT_KERNEL 2 /* Route installed by kernel */
#define RTPROT_BOOT 3 /* Route installed during boot */
#define RTPROT_STATIC 4 /* Route installed by administrator */
/* Values of protocol >= RTPROT_STATIC are not interpreted by kernel;
they are just passed from user and back as is.
It will be used by hypothetical multiple routing daemons.
Note that protocol values should be standardized in order to
avoid conflicts.
*/
#define RTPROT_GATED 8 /* Apparently, GateD */
#define RTPROT_RA 9 /* RDISC/ND router advertisements */
#define RTPROT_MRT 10 /* Merit MRT */
#define RTPROT_ZEBRA 11 /* Zebra */
#define RTPROT_BIRD 12 /* BIRD */
#define RTPROT_DNROUTED 13 /* DECnet routing daemon */
#define RTPROT_XORP 14 /* XORP */
#define RTPROT_NTK 15 /* Netsukuku */
#define RTPROT_DHCP 16 /* DHCP client */
#define RTPROT_MROUTED 17 /* Multicast daemon */
#define RTPROT_KEEPALIVED 18 /* Keepalived daemon */
#define RTPROT_BABEL 42 /* Babel daemon */
#define RTPROT_OPENR 99 /* Open Routing (Open/R) Routes */
#define RTPROT_BGP 186 /* BGP Routes */
#define RTPROT_ISIS 187 /* ISIS Routes */
#define RTPROT_OSPF 188 /* OSPF Routes */
#define RTPROT_RIP 189 /* RIP Routes */
#define RTPROT_EIGRP 192 /* EIGRP Routes */
Since NM uses only values <= RTPROT_STATIC, plus RTPROT_RA and
RTPROT_DHCP, add a BPF filter to the netlink socket to discard
notifications for other route types.
https://bugzilla.redhat.com/show_bug.cgi?id=1861527https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1038
This bumps L3_CONFIG_DATA_TYPE_MANUALIP to be the most important address
source; which is what had been the case before NetworkManager/next and
is presumably what the user expects.
It also comes into play for iBFT-booted machines, where iBFT contains a
permanent address (no lifetime data), while DHCP might lease out the
same one. In that case, expiry of the latter could potentially disrupt
connectivity to a vital storage volume.
Fixes: 14962cb414 ('merge: branch 'next''):
https://bugzilla.redhat.com/show_bug.cgi?id=2013921https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1011
