When building without "more-asserts" and LTO enabled, we can get
a warning about uninitalized "obj" variable:
src/platform/nm-linux-platform.c: In function 'ip_route_add':
src/platform/nm-platform.c:4761:24: warning: 'MEM[(struct NMPlatformIPRoute *)&obj + 24B].rt_source' may be used uninitialized in this function [-Wmaybe-uninitialized]
4761 | route->rt_source = nmp_utils_ip_config_source_round_trip_rtprot(route->rt_source);
| ^
src/platform/nm-platform.h:2139:25: warning: 'BIT_FIELD_REF <MEM[(const struct NMPlatformIPRoute *)&obj + 24B], 8, 72>' may be used uninitialized in this function [-Wmaybe-uninitialized]
2139 | return r->table_any ? 254u /* RT_TABLE_MAIN */
|
That is due to the "default" switch case which was unhandled
when building without more-asserts". Avoid that by reworking the
code.
With LTO it's easy to get "-Wmaybe-uninitialized" false positives.
But the warning is useful, we we don't want to disable it altogether.
However, while investigating the problem it can be useful to patch
it temporarily. Add a code comment that suggests how to do that.
With LTO builds we get "-Wmaybe-uninitialized" warnings, which break
the build.
These seem false positives to me, due to aggressive inlining. But also
suppressing them with a pragma does not work. So, make them non-fatal
altogether. That is unfortunate, because this warning would be useful
to catch bugs.
Interestingly, when building --with-more-asserts, then the build passes
without warning. Probably because then the inlining doesn't happen.
libtool: link: gcc -Wall -Werror -Wno-stringop-overflow -Wextra -Wdeclaration-after-statement -Wfloat-equal -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wpointer-arith -Wshadow -Wshift-negative-value -Wstrict-prototypes -Wundef -Wvla -Wno-duplicate-decl-specifier -Wno-format-truncation -Wno-format-y2k -Wno-missing-field-initializers -Wno-pragmas -Wno-sign-compare -Wno-unknown-pragmas -Wno-unused-parameter -Wno-array-bounds -Wunused-value -Wcast-function-type -Wimplicit-fallthrough -fno-strict-aliasing -fdata-sections -ffunction-sections -Wl,--gc-sections -flto -flto-partition=none -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o src/platform/tests/test-platform-general src/platform/tests/test_platform_general-test-platform-general.o src/.libs/libNetworkManagerTest.a -luuid -lgnutls -lsystemd -lndp -lselinux -L/lib64 -laudit -lpsl -lcurl -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -ludev -ldl -pthread
src/platform/nm-linux-platform.c: In function 'ip_route_add':
src/platform/nm-platform.c:4761:24: error: 'MEM[(struct NMPlatformIPRoute *)&obj + 24B].rt_source' may be used uninitialized in this function [-Werror=maybe-uninitialized]
4761 | route->rt_source = nmp_utils_ip_config_source_round_trip_rtprot(route->rt_source);
| ^
src/platform/nm-platform.h:2139:25: error: 'BIT_FIELD_REF <MEM[(const struct NMPlatformIPRoute *)&obj + 24B], 8, 72>' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2139 | return r->table_any ? 254u /* RT_TABLE_MAIN */
| ^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
When building without more-assertions and LTO, the compiler might think
that "wait" is uninitialized. Avoid the warning.
Initializing a variable is not a great solution either, because
potentially it could hide an actual bug. But it still seems to be
best.
src/nm-policy.c: In function update_system_hostname:
src/nm-policy.c:909: warning: wait may be used uninitialized in this function [-Wmaybe-uninitialized]
909 | if (wait) {
|
src/nm-policy.c:901: note: wait was declared here
901 | gboolean wait;
|
On copr builds, the unit tests sometimes fail to create a veth
interface. In those cases, kernel rejects the netlink request
with EPERM. copr uses mock on Fedora 33 hosts.
I think this is a kernel bug. Add a workaround by retrying a few times.
"shared/nm-std-aux/unaligned.h" is taken from systemd and frequently
re-imported via the "systemd" branch.
It is not our code, and should not be formatted with our clang-format.
Linux headers and some libc headers have overlapping defines
for network types and functions.
In the past years, glibc and linux headers were improved to cooperate
so you could include either one, in any order.
With musl and possibly some older glibc versions that doesn't work so
well.
Reorder and change includes to make it work better. Yes, this looks
pretty random and unmotivated. The includes are changed in order to
successfully build on various libc/kernel versions, with the goal
of not using #if.
Due to mixing includes of userspace network headers (net/*) and
kernelspace onces (linux/if*) symbol redefinitions happen on musl.
[thaller@redhat.com: modified original patch]
We were asserting against error messages from strerror(), and on libmusl
these are different. Relax the checks.
We still assert against parts of the text, where possible. So a similar
problem could happen in the future or with another libc library.
Add a new key management option to support WPA3 Enteprise wifi
connection.
Only supported with wpa_supplicant for the time being.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
In public libnm headers we include some libc/linux headers, although
libnm doesn't strictly need them.
The <linux/*.h> headers conflict with some network headers provided by
libc and they need to be included in the right order. As
<NetworkManager.h> drags in some linux headers, this makes it
unnecessarily complicated.
It also feels ugly to include headers we don't need, only for the
sake of convenience. Allow to opt out.
Also, for internal build, don't do this. When building NetworkManager
we need control about the headers and their order of inclusion.
"in_addr_t" and "struct in6_addr" require headers from libc (or linux).
In particular, some libc headers conflict with the linux headers
(or they have to be included in a specific order). To avoid that
we want that our libnm headers include a minimum of other headers
(and only drag in glib headers, which we anyway need).
- instead of "in_addr_t", use guint32. For all practical purposes,
"in_addr_t" is a plain 32 bit integers and we can do this replacement
in our public headers.
- forward declare "struct in6_addr".
Currently libnm headers include <linux/if_{ether,infiniband,vlan}.h>.
These are public headers, that means we drag in the linux header to all
users of <NetworkManager.h>.
Often the linux headers work badly together with certain headers from libc.
Depending on the libc version, you have to order linux headers in the right
order with respect to libc headers.
We should do better about libnm headers. As a first step, assume that
the linux headers don't get included by libnm, and explicitly include
them where they are needed.
These typedefs are defined by some libc headers, and we drag
them in by including some other standard headers.
It's not clear which headers we exactly need for them, and that
all libcs provide them the same.
Instead, just avoid them.
In C, includes with <> are for system headers, while "" prefers the
current working directory (implementation defined).
For libnm headers that include other libnm headers, we tend to use
"" instead of <>. That makes sense to me. Be consistent about that.
When activating a connection using nmtui, veth connections where not
being listed. This patches fixes this and they are now being listed.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
If the DNS configuration changes, the hostname previously determined
via reverse DNS lookup could be stale. Clear the resolver data of every
interface and try again.
Fixes: 09c8387114 ('policy: use the hostname setting')
Veth interfaces should be shown as Ethernet from
nm_device_get_type_description in order to provide backward
compatibility.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
As NMDeviceVeth has a NMDeviceEthernet as parent, it should use PRIO_20
in order to report NMDeviceVeth when configured and do not report
NMDeviceEthernet.
An unit test case has been added.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
