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')
We still use the "gs_*" macros that we originally got from libgsystem.
libgsystem no longer exists, we only still use the names of these
macros.
Our own cleanup macros all follow the "nm_auto*" naming pattern.
Eventually, we want to replace all uses of "gs_*" with cleanup macros
that follow our naming scheme.
Add the macros that will be used to replace the "gs_*" macros.
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.
nm_setting_ip4_config_get_dhcp_vendor_class_identifier() was
backported to nm-1-26 branch, and will be released as 1.26.4.
As such, on the stable branch the symbol will be placed in a
separate symbol version ("libnm_1_26_4").
To support the upgrade path from 1.26.4+ to 1.28+, we
want this symbol also present on master.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Use a macro that uses NM_CAST_STRV_CC() to cast the strv argument. Note that
NM_CAST_STRV_CC() uses C11's _Generic() to check whether the argument is
of a valid type.
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>
