The change broke unit tests on 32 bit systems.
Change the code again to make it more similar to what it was
before. Now only on 64 bit systems there is any difference compared
to before. That makes it easier about reasoning for how the unit test
should be (in most cases, it is unchanged).
Fixes: 040c86f15c ('shared: avoid compiler warning for nm_utils_get_next_realloc_size() returning huge sizes')
With LTO enabled, the compiler might think that "len" is not initialized.
That is even a correct assumption, if the compiler does not understand the
API of sendmsg() and that sendmsg() is supposed to set a negative errno.
Work around by initializing the variable.
shared/n-dhcp4/src/n-dhcp4-c-connection.c: In function n_dhcp4_c_connection_send_request:
shared/n-dhcp4/src/n-dhcp4-socket.c:368:19: error: len may be used uninitialized in this function [-Werror=maybe-uninitialized]
} else if (len != n_buf) {
^
shared/n-dhcp4/src/n-dhcp4-socket.c:351:23: note: len was declared here
size_t n_buf, len;
^
On s390x (gcc-8.3.1-5.1.el8.s390x) the compiler warns that we don't
pass size larger than 2^63-1 to malloc. With LTO enabled, it is also
quite adamant in detecting that with nm_utils_get_next_realloc_size().
Optimally, we would disable this useless warning with "-Wno-alloc-size-larger-than",
but that seems not to work. So add a workaround in code :(
It's hard to actually workaround the warning while handling all kinds of
sizes. The only simple solution is to no handle such huge cases and only
assert.
In function 'nm_secret_mem_realloc',
inlined from '_nm_str_buf_ensure_size' at shared/nm-glib-aux/nm-shared-utils.c:5316:31:
shared/nm-glib-aux/nm-secret-utils.h:180:17: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
m_new = g_malloc(new_len);
^
shared/nm-glib-aux/nm-secret-utils.h: In function '_nm_str_buf_ensure_size':
/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function 'g_malloc' declared here
gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1);
^
lto1: all warnings being treated as errors
This file has no relevance for NetworkManager. And we should not deviate
from upstream n-dhcp4 which we include via git-subtree. Revert the
change.
This partly reverts commit 7f4a7bf433.
"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.
On alpine/musl we get a compiler warning:
CC shared/systemd/src/basic/libnm_systemd_shared_la-env-file.lo
In file included from ../shared/systemd/src/basic/fileio.h:9,
from ../shared/systemd/src/basic/env-file.c:10:
/usr/include/sys/fcntl.h:1:2: error: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h> [-Werror=cpp]
1 | #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h>
| ^~~~~~~
<netinet/ether.h> with musl defines ethhdr struct, which conflicts
with <linux/if_ether.h>. The latter is included by "nm-utils.h",
so this is a problem.
Drop includes of "netinet/ether.h" that are not necessary.
We cannot drop the reference count to zero while having
no lock. Otherwise, another thread might race doing
s = nm_ref_string_new("...");
nm_ref_string_unref(s);
and already successfully delete the instance.
Hitting this race should be rather difficult, especially because
we tend to use NMRefString only from one thread. But still, access
to global variables must be race free.
Fixes: 908fadec96 ('shared: add NMRefString')
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The macro should require exactly 6 parameters (for the 6 bytes
of the address). On the other hand, we also should be able to
use a macro like
NM_ETHER_ADDR_INIT(NM_BRIDGE_GROUP_ADDRESS_DEF_BIN)
To get that work properly, we need to expand the variadic macro
once.
Also, cast the result to the struct type. With this, it can
not only be used for initialization, but also for assignment
and temporary variables.
We have:
- nm_utils_hashtable_cmp(): this does a full cmp of two hash
tables, with the intent to provide a stable sort order.
It thus takes a GCompareDataFunc() argument.
- nm_utils_hashtable_cmp_equal(): this is like nm_utils_hashtable_cmp(),
except that the caller won't get a compare value, only a boolean
value that indicates equality.
This was previously called nm_utils_hashtable_equal().
- nm_utils_hashtable_equal(): this takes a GEqualFunc function
for comparing the values for equality. It takes thus
a different kind of predicate, but otherwise is similar to
nm_utils_hashtable_cmp_equal().
This was previously called nm_utils_hash_table_equal().
Unify the naming of these functions.
When including <glib.h>, it will always define G_LOG_DOMAIN if it
is not yet defined.
Usually we want to include "nm-default.h" as very first header. In that
case, <glib.h> is not yet included. Then the previous check #error works
well.
However, if we include "nm-default.h" in sources generated by
glib-mkenums, then the generator first already includes <glib.h>,
and thus defines G_LOG_DOMAIN. It does so for "libnm-core/nm-core-enum-types.c"
and "libnm/nm-enum-types.c", where the #error would not trigger.
But we will also include "nm-default.h" for "libnm-core/tests/nm-core-tests-enum-types.c".
That will start triggering this #error.
While in general we want to include "nm-default.h" first, we also need
to support cases where <glib.h> gets included first. Thus this error is
not useful. Remove it.
It's not strictly necessary, because contrary to g_atomic_pointer_get()
and g_atomic_pointer_compare_and_exchange(), glib's variant for the
setter is mostly fine.
Still, reimplement it, because we use typeof() eagerly and can thus add
more static checks than glib.
It seems it can happen that the service is not yet unregistered from the
D-Bus broker, even if we already reaped the PID.
/builds/NetworkManager/NetworkManager/tools/run-nm-test.sh --called-from-make /builds/NetworkManager/NetworkManager/build --launch-dbus=auto /builds/NetworkManager/NetworkManager/build/libnm/tests/test-nm-client
--- stdout ---
/libnm/device-added:
nmtst: initialize nmtst_get_rand() with NMTST_SEED_RAND=0
--- stderr ---
**
test:ERROR:../shared/nm-test-utils-impl.c:216:nmtstc_service_cleanup: assertion failed: (!name_exists(info->bus, "org.freedesktop.NetworkManager"))
Workaround by waiting a bit.
We now iterate the main GMainContext, unlike before. But that
should not cause any problems for the test.
These macros are consistent with NMP_OBJECT_TYPE_IP_ADDRESS()
and NMP_OBJECT_TYPE_IP_ROUTE(), in name and usage.
Replace the previous functions that had inconsistent and a verbose
naming.
nmtst_main_context_iterate_until() is a macro, and we don't want to restrict the
valid integer type (or range) of the "timeout_msec" argument.
In particular, if the user calculates a timeout with "timestamp_msec -
now_msec", the resulting "timeout_msec" might be a negative gint64.
We should handle that gracefully, and not let it be cast to a huge
unsigned int.
