Code doesn't get simpler by having more functions -- if these functions
are only called once.
What actually is a problem is repeated, redundant code. Like the list of
bond options that can be reapplied. But the function didn't help to
avoid repeating the list.
Add a macro for the list of bond options we are going to set. By seeing
them side-by-side, it is hopefully simpler to see that all options are
specified correctly.
We see that:
- the *_SUBSET defines don't include the options that we are explicitly
setting, that is "mode", "active_slave" and "arp_ip_target".
- OPTIONS_REAPPLY_SUBSET contains 4 options less than OPTIONS_APPLY_SUBSET:
"ad_select", "ad_user_port_key", "lacp_rate" and "tlb_dynamic_lb".
These are the options that are marked as BOND_OPTFLAG_IFDOWN in
kernel.
I guess the idea was to only accept options that can be changed without
taking the interface !IFF_UP. "active_slave" is wrongly omitted from
that list.
Also, "active_slave" option doesn't really make sense for NetworkManager
to configure. Instead "primary" should be used. In the future, we should
re-map the properties and deprecate "active_slave" for "primary" ([1]).
Fixes: 746dc119a6 ('bond: let 'reapply()' reapply all supported options')
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1856640#c19https://bugzilla.redhat.com/show_bug.cgi?id=1876577
NMDBusObject is an abstract type which provides the glue code for exposing
a GObject on D-Bus. We almost never use that type directly, so as it was
before, we always had to use a C cast to convince the compiler that this
is right.
Being always required to cast is not very useful, nor more typesafe.
Just use a void pointer instead.
NML3Cfg manages one ifindex. In the future, we may want that multiple
NMDevice and/or NMVpnConnection instances independently contribute their
NML3ConfigData to the NML3Cfg instance.
That means, at any time somebody may want to call nm_l3cfg_platform_commit()
to apply the changes. Even ACD internally may do that, when configuration
changes (e.g. an IP address passes ACD check). We thus need to know
whether we are assuming, updating or reapplying the settings.
Add API so users can register their "commit" preference.
The current approach also tracks external configuration in an NMIP[46]Config, and
we need to special handle those. In the future, we only want to track what we actually
want to configure. So this flag won't be used with NML3Cfg/NML3ConfigData.
Currently, NMDevice does ACD. It intercepts certain NMIP4Config
instances, and tries to perform ACD on the addresses. I think this
functionality should be handled by NML3Cfg instead.
For one, NML3Cfg sees all configurations, and can perform ACD for all
(relevant) addresses. Also, it moves logic away from NMDevice and makes
the functionality available without an NMDevice. As such, it also will
allow that independent "controllers" contribute NML3ConfigData instances
and ACD will performed for all of them (as requested).
This will be our implementation for IPv4 ACD (https://tools.ietf.org/html/rfc5227)
based on nettools' n-acd library.
The code is not actually tested yes, because NMDevice did not yet switch
over to use NML3Cfg. Once that happens, surely issues with this patch
will be found that will need fixing.
Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.
Fixes: c056cb9306 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')
The "gs_*" macros originate from the (no longer existing) libgsystem library.
We still have them, because so far we didn't go through the effort of
renaming the API.
Aside that oddity, our cleanup API is called "nm_auto*". There is no need
to add new API with the old name.
When a virtual device fails, its state goes to FAIL and then
DISCONNECTED. In DISCONNECTED we call schedule_activate_check() to
schedule an auto-activation if needed. We also schudule the deletion
of the link through delete_on_deactivate_check_and_schedule(). The
auto-activation attempt fails because the link deletion unmanages the
device; as a result, the device doesn't try to auto-activate again.
To fix this:
- don't allow the device to auto-activate if the device deletion is
pending;
- check again if the device can be auto-activated after its deletion.
https://bugzilla.redhat.com/show_bug.cgi?id=1818697https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/613
With LTO we get a compiler warning:
src/dhcp/nm-dhcp-systemd.c: In function dhcp_event_cb:
src/dhcp/nm-dhcp-systemd.c:554: error: lease may be used uninitialized in this function [-Werror=maybe-uninitialized]
554 | r = sd_dhcp_lease_get_server_identifier (lease, &addr);
|
src/dhcp/nm-dhcp-systemd.c:528: note: lease was declared here
528 | sd_dhcp_lease *lease;
|
Fixes: 7f217d0345 ('core: honor the ipv4.dhcp-reject-servers property')
Avoids a compiler warning:
../src/devices/nm-device.c:16079:26: error: cast to smaller integer type 'NMDeviceStateReason' from 'gpointer' (aka 'void *') [-Werror,-Wvoid-pointer-to-enum-cast]
deactivate_ready (self, (NMDeviceStateReason) reason);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 121c58f0c4 ('core: set number of SR-IOV VFs asynchronously')
"XXX" is used for tagging parts of code that still need work before
merging a patch. If you want to highlight/mark a comment which is merged
use either "TODO" or "FIXME".
Of course, even "TODO" and "FIXME" should be avoided in favor of just
doing/fixing it. Such things tend to never be done/fixed.
Add a new `main.rc-manager=auto` setting, that favours to use
systemd-resolved (and not touch "/etc/resolv.conf" but configure
it via D-Bus), or falls back to `resolvconf`/`netconfig` binaries
if they are installed and enabled at compile time.
As final fallback use "symlink", like before.
Note that on Fedora there is no "openresolv" package ([1]). Instead, "systemd"
package provides "/usr/sbin/resolvconf" as a wrapper for systemd-resolved's
"resolvectl". On such a system the fallback to resolvconf is always
wrong, because NetworkManager should either talk to systemd-resolved
directly or not but never call "/usr/sbin/resolvconf". So, the special handling
for resolvconf and netconfig is only done if NetworkManager was build with these
applications explicitly enabled.
Note that SUSE builds NetworkManager with
--with-netconfig=yes
--with-config-dns-rc-manager-default=netconfig
and the new option won't be used there either. But of course, netconfig
already does all the right things on SUSE.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=668153
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Arguably, a fixme comment isn't useful. It would be better to fix it.
On the other hand, nowadays these modes are not very popular and usually
not used. If somebody cares, please provide a patch.
The kernel of Ubuntu 16.04 doesn't support IFLA_BR_VLAN_STATS_ENABLED.
If we want to run on such old kernels (which we probably do), we need to
detect that, and act accordingly.
Add nm_platform_kernel_support_get_full() to allow fetching the support
state without setting it to the compile time default.
Also, use g_atomic_int_get() to access _nm_platform_kernel_support_state
values. We should not access static variables without synchronization.
Better get it correct in any case than fast.
We use a linker version script "NetworkManager.ver", to hide
symbols from NetworkManager that are not used. That is important
due to our habit of using internal helper libraries that we link
statically everywhere, without handpicking the symbols we actually
need. We want the tooling to get rid of unnecessary symbols.
However, NetworkManager loads shared libraries for settings and device
plugins. These libraries require symbols from the NetworkManager binary,
but which one depends on build options. Hence, we also generate
"NetworkManager.ver" by the "tools/create-exports-NetworkManager.sh"
script.
For that the script uses "nm" to find symbols that are undefined in the
plugin libraries but defined in NetworkManager. With autotools the
script looked at "./src/.libs/libNetworkManager.a" to find the present
symbols. Note that for meson that already didn't work, and we build
instead an intermediate NetworkManager binary first (with all symbols
exposed). With LTO, "nm" doesn't find all symbols in
"./src/.libs/libNetworkManager.a", and consequently they are not
exported and dropped/hidden.
This also causes unit tests to fail with LTO, because our test script
"tools/check-exports.sh" catches such bugs.
Fix that by also with autotools generate a complete "NetworkManager-all-sym"
binary that is used to generate "NetworkManager.ver", before rebuilding
"NetworkManager" again.
