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')
(cherry picked from commit bff23d15d4)
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
(cherry picked from commit e404585e60)
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')
(cherry picked from commit 918ebd600a)
With Fedora 33, LTO will be enabled by default via CFLAGS in
redhat-rpm-config ([1]).
That basically sets "CFLAGS=-flto -ffat-lto-objects".
Note that we have our own configure/meson option to enable LTO.
With "--with-lto" we set CFLAGS="-flto -flto-partition=none". This
is necessary due ([2], [3]).
So, disable Fedora's automatism, but turn on the suitable configure
option to get working LTO.
[1] 5baaf4a99c
[2] e6cf4213a7 ('build: fix building with LTO')
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200#c28
(cherry picked from commit 839ba57c7f)
No amount of _Pragma was able to disable this warning.
In function ‘strncpy’,
inlined from ‘_nm_strndup_a_step’ at ./shared/nm-glib-aux/nm-macros-internal.h:1367:3,
inlined from ‘nms_keyfile_nmmeta_check_filename’ at src/settings/plugins/keyfile/nms-keyfile-utils.c:61:0:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^
src/settings/plugins/keyfile/nms-keyfile-utils.c: In function ‘nms_keyfile_nmmeta_check_filename’:
src/settings/plugins/keyfile/nms-keyfile-utils.c:44: note: length computed here
44 | len = strlen (filename);
|
lto1: all warnings being treated as errors
Oddly enough, gcc is still emitting the warning even with "-Wno-stringop-overflow",
but at least it doesn't break the build.
(cherry picked from commit 407a1f1e98)
nmcli is build with libtool, so "clients/cli/nmcli" is really a shell script
that invokes the real nmcli (at "clients/cli/.libs/nmcli").
When building with LTO for some reasons "clients/cli/nmcli" still
does some build steps during the first invocation.
That means, if we run `make check-local-clients-tests-test-client` it
would first do the final build step. This takes a while, and the test
times out (worse, we do that build step many times in parallel).
Avoid that by invoking "clients/cli/nmcli" first.
(cherry picked from commit 00e3fc036a)
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.
(cherry picked from commit c92a3ca5c2)
On Debian sid, pygobject no longer builds "python-gobject" for
python2. Still, python2 may be installed and detected preferably
by AM_PATH_PYTHON(). Add workaround.
(cherry picked from commit 54a1cfa973)
The matchfilecon API is deprecated for a very long time. Since selinux 3.1
the functions are also marked as deprecated in the header, which causes
compiler warnings and build failures.
Update the code to use selabel API instead.
(cherry picked from commit 173533c3b2)
Seems with LTO the compiler can sometimes think that thes variables are
uninitialized. Usually those code paths are only after an assertion was
hit (g_return*()), but we still need to workaround the warning.
(cherry picked from commit 70971d1141)
With LTO and optimizations enabled, we get a compiler warning about fd_udp
not initialized:
../src/n-dhcp4-c-connection.c: In function ‘n_dhcp4_c_connection_connect’:
../src/n-dhcp4-c-connection.c:196:13: error: ‘fd_udp’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
196 | r = epoll_ctl(connection->fd_epoll,
| ^
../src/n-dhcp4-c-connection.c:185:16: note: ‘fd_udp’ was declared here
185 | int r, fd_udp;
| ^
6c6e936898
(cherry picked from commit 4e0e002092)
gcc-10.2.1-1.fc32 with optimizations and LTO enabled can think that "len"
is uninitialized. Let packet_recv_udp() always set the length.
../src/n-dhcp4-socket.c: In function ‘n_dhcp4_c_socket_packet_recv.constprop’:
../src/n-dhcp4-incoming.c:210:29: error: ‘len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
210 | incoming->n_message = n_raw;
| ^
../src/n-dhcp4-socket.c:558:16: note: ‘len’ was declared here
558 | size_t len;
| ^
142eedcfc3
(cherry picked from commit 08318a0bac)
Currently, we would not mark non-unicast routes with their type, so they
would wrongly appear as unicast routes in the D-Bus API.
That is wrong. For now, just hide them.
Fixes: 5d0d13f570 ('platform: add support for local routes')
(cherry picked from commit 5035687a7b)
Imagine we wait for a device, the device appears and starts activating.
That might take a while (during which it has a pending action). In the
meantime, the "connection.wait-device-timeout" timeout expires.
Now we want to log a warning about profiles that don't have their
device upon timeout. However, that the device is still busy at that
point is irrelevant. Skip logging a message about those profiles.
Fixes: 3df662f534 ('settings: rework wait-device-timeout handling and consider device compatibility')
(cherry picked from commit d9568ca3ee)
Since commit 3df662f534 ('settings: rework wait-device-timeout
handling and consider device compatibility'), "connection.wait-device-timeout"
works with profiles in general and doesn't require an interface-name
set.
Remove that restriction and let initrd generator create profiles that
always wait.
(cherry picked from commit 52af5e901e)
The network-legacy dracut module waits for all ethernet devices if the
command line contains rd.neednet=1. It also waits for the device
specified by 'bootdev='.
Do the same.
https://bugzilla.redhat.com/show_bug.cgi?id=1853348
(cherry picked from commit f114e16fdd)
A profile can configure "connection.wait-device-timeout" to indicate
that startup complete is blocked until a suitable device around.
This is useful for NetworkManager-wait-online and initrd mode.
Previously, we looked at NMPlatform whether a link with matching
interface-name was present. That is wrong because it cannot handle
profiles that rely on "ethernet.mac-address" setting or other "match"
settings. Also, the mere presence of the link does not yet mean
that the NMDevice was created and ready. In fact, there is a race here:
NMPlatform indicates that the device is ready (unblocking NMSettings),
but there is no corresponding NMDevice yet which keeps NetworkManager
busy to block startup complete.
Rework this. Now, only check whether there is a compatible device for
the profile.
Since we wait for compatible devices, it works now not only for the
interface name. Note that we do some optimizations so that we don't have
to re-evaluate all profiles (w.r.t. all devices) whenever something on the
device changes: we only care about this when all devices finally become
ready.
Also, we no longer start the timeout for "connection.wait-device-timeout"
when the profile appears. Instead, there is one system-wide start time
(NMSettingsPrivate.startup_complete_start_timestamp_msec). That simplifies
code and makes sense: we start waiting when NetworkManager is starting, not
when the profile gets added. Also, we wait for all profiles to become
ready together.
(cherry picked from commit 3df662f534)
NMSettings needs access to the list of all devices, which is tracked
by NMManager. Of course, this ties NMSettings and NMManager closer
together. Note that NMManager already owns a reference to NMSettings,
so they are in fact related.
The alternatives of just letting NMSettings reference NMManager (and
vice versa) would be more complicated, and likely not help to simplify
the code (on the contrary).
(cherry picked from commit d27a6055b9)
Reapply now handles all the options supported by kernel and NM, meaning
that some options are simply not allowed to be set while keeping the
bond up, one of those options is the mode for instance.
https://bugzilla.redhat.com/show_bug.cgi?id=1847814
(cherry picked from commit 746dc119a6)
can_reapply_change() would wrongly return true for
unsupported reapply values because it used 'nm_setting_bond_get_option_default()'
that is ill-named because it returns the overriden option other than
its default value.
https://bugzilla.redhat.com/show_bug.cgi?id=1847814
Fixes: 9bd07336ef ('bond: bond options logic rework')
(cherry picked from commit 04d6ca1fb8)
