Since normalize already sorts the array, and verify needs to check
whether the array is sorted, we can implement verify() more efficiently.
In the usual case (where the property is normalized), we can just
iterate over the list and check that the ranges are increasing and
non-overlapping.
Only if that fails, do a shallow-copy of the array, sort it, and check
again. If it's still invalid after sorting, verification fails.
We don't need to create a GHashTable which adds all elements in between
the ranges. While the algorithm with hash table is O(n), the new version
with sorting is O(n*ln(n)). But of course, since the overall number of
range elements is limited to 4096, they are really both O(1). But more
importantly, it's just faster to iterate over the list and sort it, than
to fill a hash table.
---
Test with -O2, more-asserts=0:
diff --git c/src/libnm-core-impl/tests/test-setting.c w/src/libnm-core-impl/tests/test-setting.c
index 00fc838d1794..a0991b36d9d7 100644
--- c/src/libnm-core-impl/tests/test-setting.c
+++ w/src/libnm-core-impl/tests/test-setting.c
@@ -5266,5 +5266,5 @@ static void
test_ovs_port_trunks(void)
{
- const guint N_RUN = 10;
+ const guint N_RUN = 10000;
guint i_run;
gs_unref_object NMConnection *con = NULL;
$ make -j src/libnm-core-impl/tests/test-setting && \
libtool --mode=execute \
perf stat -r 5 -B \
src/libnm-core-impl/tests/test-setting -p /libnm/test_ovs_port_trunks
Before:
8,114.55 msec task-clock:u # 0.998 CPUs utilized ( +- 0.20% )
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
341 page-faults:u # 41.980 /sec ( +- 0.16% )
25,172,559,932 cycles:u # 3.099 GHz ( +- 0.12% )
39,221,096,221 instructions:u # 1.56 insn per cycle ( +- 0.04% )
5,721,519,798 branches:u # 704.373 M/sec ( +- 0.07% )
230,728,395 branch-misses:u # 4.04% of all branches ( +- 0.28% )
8.1340 +- 0.0179 seconds time elapsed ( +- 0.22% )
After:
4,300.62 msec task-clock:u # 0.999 CPUs utilized ( +- 0.34% )
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
342 page-faults:u # 79.435 /sec ( +- 0.20% )
13,231,554,996 cycles:u # 3.073 GHz ( +- 0.27% )
20,676,554,955 instructions:u # 1.55 insn per cycle ( +- 0.07% )
3,101,429,604 branches:u # 720.354 M/sec ( +- 0.11% )
118,808,950 branch-misses:u # 3.83% of all branches ( +- 0.34% )
4.3068 +- 0.0143 seconds time elapsed ( +- 0.33% )
Most of the time properties are unset/empty. It's wasteful to allocate
the GPtrArray before it's actually needed.
Also, because the GObject property setter will throw away the old
GPtrArray and allocate a new one. So if you use that setter, the
previous instance is rather useless.
When only running a subset of the tests (with "-p"), then valgrind
indicates a leak. Avoid that.
$ ./tools/run-nm-test.sh -m src/core/platform/tests/test-route-linux -v
# no leak
$ ./tools/run-nm-test.sh -m src/core/platform/tests/test-route-linux -v -p /route/ip4
# many leaks:
==1662102== 107 (96 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 388 of 448
==1662102== at 0x4848464: calloc (vg_replace_malloc.c:1340)
==1662102== by 0x4F615F0: g_malloc0 (gmem.c:163)
==1662102== by 0x1621A6: _nmtst_add_test_func_full (nm-test-utils.h:918)
==1662102== by 0x1623EB: _nmtstp_setup_tests (test-route.c:2179)
==1662102== by 0x16E53D: main (test-common.c:2693)
==1662102==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:calloc
fun:g_malloc0
fun:_nmtst_add_test_func_full
fun:_nmtstp_setup_tests
fun:main
}
This allows to free resources (a pointer) at the end of the test.
The purpose is to avoid valgrind warnings about leaks. While a leak
in the test is not a severe issue by itself, it does interfere with
checking for actual leaks. Thus every leak must be avoided.
Only allocate one chunk of memory to contain all data of
NmtstTestData.
This isn't about performance (which doesn't matter for test code).
It's about packing all in one struct and being able to free all at
once with a simple g_free(). We no longer need _nmtst_test_data_free()
with this.
Note that NmtstTestData is never mutated, it just holds some data.
As such, the single place where such a structure gets initialized,
can become a bit more complicated, in exchange for having a trivial
free operation (and anyway there no functions that modify the data
or that would care about the data layout).
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e1 ('platform: manage ECMP routes')
There are two callers of available_connections_add(). One from
cp_connection_added_or_updated() (which is when a connection
gets added/modified) and one from nm_device_recheck_available_connections().
They both call first nm_device_check_connection_available() to see
whether the profile is available on the device. They certainly
need to pass the same check flags, otherwise a profile might
be available in some cases, and not in others.
I didn't actually test this, but I think this could result
in a profile wrongly not being listed as an available-connection.
Moreover, that might mean, that `nmcli connection up $PROFILE`
might work to find the device/profile, but `nmcli device up $DEVICE`
couldn't find the suitable profile (because the latter calls
nm_device_get_best_connection(), which iterates the
available-connections). I didn't test this, because regardless of
that, it seems obvious that the conditions for when we call
available_connections_add() must be the same from both places.
So the only question is what is the right condition, and it would
seem that _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST is the right
flag.
Fixes: 02dbe670ca ('device: for available connections check whether they are available for user-request')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1496
$ nmcli --offline connection add type wifi con-name hotspot ssid hotspot-ssid wifi.mode ap wifi-sec.key-mgmt none wifi-sec.wep-key-type 1 wifi-sec.wep-key0 1234567890
would previously always print a message
Info: WEP key is guessed to be of '1 (key)'
At least, when we explicitly set the key-type, this message is bogus.
Suppress it.
It's anyway questionable whether printing such warnings does anything good.
We would still get the warning with the arguments swapped, which seems wrong:
$ nmcli --offline connection add type wifi con-name hotspot ssid hotspot-ssid wifi.mode ap wifi-sec.key-mgmt none wifi-sec.wep-key0 1234567890 wifi-sec.wep-key-type 1
Info: WEP key is guessed to be of '1 (key)'
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1497
iptables takes a file lock at /run/xtables.lock. By default, if
the file is locked, iptables will fail with error. When that happens,
the iptables rules won't be configured, and the shared mode
(for which we use iptables) will not be setup properly.
Instead, pass "--wait 2", to block. Yes, it's ugly that we use
blocking program invocations, but that's how it is. Also, iptables
should be fast to not be a problem in practice.
Next, support for "other_config" will be added. That is very similar
to "external_ids". Extend the existing code, to make that next update
simpler. The only purpose of this patch, is to reduce the diff of
when actually adding "other_config". Only in light of that, do some
of the changes here make sense.
We will add support for "other_config". This is in many aspects similar
to "external-ids". So first do a renaming, so that the code can be
sensibly reused. This is a separate patch, so that the followup commit
has less noise in the diff.
This function *only* renames (and reformats). No other changes.
"mutate" with operation "insert" does not update existing entries.
Delete them first.
Otherwise, a reapply that only change the value of an external-ids
entry does not work.
Note that https://www.rfc-editor.org/rfc/rfc7047 says about
"<mutations>":
If <mutator> is "insert", then each of the key-value pairs in
the map in <value> is added to <column> only if its key is not
already present. The required type of <value> is slightly
relaxed, in that it may have fewer than the minimum number of
elements specified by the column's type.
Fixes: 7055539c9f ('core/ovs: support setting OVS external-ids')
Doing an "update" is wrong, because that will replace all "other_config"
entries. We only want to reset the "hwaddr".
Note that https://www.rfc-editor.org/rfc/rfc7047 says about
"<mutations>":
If <mutator> is "insert", then each of the key-value pairs in
the map in <value> is added to <column> only if its key is not
already present. The required type of <value> is slightly
relaxed, in that it may have fewer than the minimum number of
elements specified by the column's type.
That means, we need to first delete, and then insert the key.
Fixes: 5d4c8521a3 ('ovs: set MAC address on the bridge for local interfaces')
Iterating over a hash table is not deterministic. When we have
two invalid keys in ovs-external-ids, we should deterministically
get the same error message.
Instead, iterate over the (sorted) keys. This does have an overhead,
because we need to fetch the keys, and we need to lookup each value
by key. Still, correctness and determinism is more important.
The same will also be used by "ovs-other-config". Also, there should be
a general concept, meaning, we should have a function whether a character
is from some benign set, and not whether we have a character usable for
keys of "ovs-external-ids".
New files must be written to the build directory, not to the source
one.
Fixes: 5ee2f3d1dc ('dhcp/tests: refactor tests for nm_dhcp_dhclient_save_duid()')
When the connection setting changes at the first place, then calling
the device reapply, the ip address got temporarily removed when DHCP
restarted. To avoid the ip address got temporarily removed, we should
preserve the previous lease and keep using it until the new lease comes
along.
This adjusts the change from commit ffbcf01589 ('test-ndisc-fake:
free l3cfg after creating fake-ndisc').
ndisc_new() already correctly handles the reference count of l3cfg via
"gs_unref_object". The party that took the wrong reference was
nm_fake_ndisc_new().
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
When committing ECMP routes we are cleaning up dirty routes and freeing
the EcmpTrackObj. We need to free EcmpTrackObj only when it is not
needed anymore so it is the last thing we do when cleaning up the
routes.
Considering nm_netns_l3cfg_acquire returns a l3cfg reference and only
keeps a weak reference we need to free l3cfg in fake-ndisc after
creating the object.
If an L3Cfg try to register an ECMP route that we are tracking we must
mark it as needs_update because it means it could be dropped from
kernel. When merging them if the merged route didn't change we should
commit the route anyway because we know it needed update.
When adding a static route, kernel enforce that the gateway is
reachable. To solve this, NetworkManager generates onlink routes for
each static route. As ECMP routes does not follow the same logic than
singlehop routes, we need to add the onlink route for each hop of ECMP
routes once merged.
NML3Cfg will take ownership of the onlink route added and will purge it
when it is not needed anymore.
NML3Cfg and NMNetns are already strongly related and cooperate.
An NML3Cfg instance is created via NMNetns, which is necessary
because NMNetns ensures that there is only one NML3Cfg instance per
ifindex and it won't ever make sense to have multiple NML3Cfg instances
per namespace.
Note that NMNetns tracks additional information for each NML3Cfg.
Previously, in a pointless attempt to separate code, it did so
by putting that information in another struct (L3CfgData).
But as the classes are strongly related, there really is no
reason why we cannot just attach this information to NML3Cfg
directly. Sure, we want that code has low coupling, high cohesion
but that doesn't mean we gain anything by putting data that is
strongly related to the NML3Cfg to another struct L3CfgData.
The advantage is we save some redundant data and an additional
L3CfgData. But the bigger reason is that with this change, it
will be possible to access the NMNetns specific data directly from
an NML3Cfg instance, without another dictionary lookup. Currently
such a lookup is never used, but it will be.
Basically, NML3Cfg and NMNetns shares some state. It is now in the
"internal_netns" field of the NML3Cfg instead of L3CfgData.
The current implementation of libnm guarantees that "o" and "ao"
properties are cleared when the device object goes away, i.e. when all
its interfaces disappear from the bus.
The "manager:device-removed" signal is emitted just before the device
is unexported, and usually properties are not cleared at that
time. So, the assertions about empty available connections and active
connection during "device-removed" seem wrong; remove them.
Whether the test passes or not depends on a race condition in the way
the mock NM service is stopped: we first close the pipe to the process
to force a clean shutdown (where all objects are orderly unexported)
but just after that we send SIGTERM which causes the service to drop
from the bus.
If libnm sees the service dropping from the bus, it deletes all
objects (thus clearing properties) and then emits
"device-removed"; in this case the test passes.
However in case of a clean shutdown, NM first emits the
"device-removed" signal and then unexports devices, leading to a
failure.
Fixes: aaa9a9cd25 ('libnm/client: don't reset properties when interface goes away')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1486
src/core/devices/nm-lldp-listener.c:911: check_after_deref:
Null-checking "self" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
Fixes: 04e72b6b4d ('lldp: use new libnm-lldp instead of systemd's sd_lldp_rx')
src/nmcli/devices.c:1196: double_free: Calling "_nm_auto_strfreev" frees pointer "arg_arr" which has already been freed.
Fixes: c5d45848dd ('cli: mark argv argument for command line parsing as const')
