Commit graph

9 commits

Author SHA1 Message Date
Thomas Haller
623012c14a
core: rate-limit updates to IP addresses/routes on D-Bus API
It doesn't scale. If you add 100k routes one-by-one, then upon each
change from platform, we will send the growing list of the routes on
D-Bus.

That is too expensive. Especially, if you imagine that the receiving end
is a NMClient instance. There is a D-Bus worker thread that queues the
received GVariant messages, while the main thread may not be able to
process them fast enough. In that case, the memory keeps growing very
fast and due to fragmentation it is not freed.

Instead, rate limit updates to 3 per second.

Note that the receive buffer of the netlink socket can fill up and we
loose messages. Therefore, already on the lowest level, we may miss
addresses/routes. Next, on top of NMPlatform, NMIPConfig listens to
NM_L3_CONFIG_NOTIFY_TYPE_PLATFORM_CHANGE_ON_IDLE events. Thereby it
further will miss intermediate state (e.g. a route that exists only for
a short moment).

Now adding another delay and rate limiting on top of that, does not make
that fundamentally different, we anyway didn't get all intermediate states
from netlink. We may miss addresses/routes that only exist for a short
amount of time. This makes "the problem" worse, but not fundamentally
new.

We can only get a (correct) settled state, after all events are
processed. And we never know, whether there isn't the next event
just waiting to be received.

Rate limiting is important to not overwhelm D-Bus clients. In reality,
none of the users really need this information, because it's also
incomplete. Users who really need to know addresses/routes should use
netlink or find another way (a way that scales and where they explicitly
request this information).
2023-11-30 15:41:43 +01:00
Beniamino Galvani
a7412e2c65
core: rename and move nm_ip_config_dns_hash()
The function operates on a NML3ConfigData, rename it and move it to
the right place.

(cherry picked from commit ec0a83b224)
2023-02-07 13:46:14 +01:00
Thomas Haller
0b1177cb18
all: use _NM_G_TYPE_CHECK_INSTANCE_CAST() for internal uses
G_TYPE_CHECK_INSTANCE_CAST() can trigger a "-Wcast-align":

    src/core/devices/nm-device-macvlan.c: In function 'parent_changed_notify':
    /usr/include/glib-2.0/gobject/gtype.h:2421:42: error: cast increases required alignment of target type [-Werror=cast-align]
     2421 | #  define _G_TYPE_CIC(ip, gt, ct)       ((ct*) ip)
          |                                          ^
    /usr/include/glib-2.0/gobject/gtype.h:501:66: note: in expansion of macro '_G_TYPE_CIC'
      501 | #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
          |                                                                  ^~~~~~~~~~~
    src/core/devices/nm-device-macvlan.h:13:6: note: in expansion of macro 'G_TYPE_CHECK_INSTANCE_CAST'
       13 |     (G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_DEVICE_MACVLAN, NMDeviceMacvlan))
          |      ^~~~~~~~~~~~~~~~~~~~~~~~~~

Avoid that by using _NM_G_TYPE_CHECK_INSTANCE_CAST().

This can only be done for our internal usages. The public headers
of libnm are not changed.
2022-12-16 10:55:03 +01:00
Thomas Haller
615221a99c format: reformat source tree with clang-format 13.0
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.

So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.

As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).

The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as

  Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)

[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-29 09:31:09 +00:00
Wen Liang
8995d44a0b core: compare the DNS configurations before updating DNS
DNS manager always sets `priv->config_changed = TRUE` and overwrites
the "resolv.conf" file. To fix it, compare the new configuration with
the old configuration, if there is no change, skipping the update.

Fixes-test: @ipv4_ignore_resolveconf_with_ignore_auto_dns
Fixes-test: @ipv4_ignore_resolveconf_with_ignore_auto_dns_var1

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1023
2021-11-18 16:21:34 +01:00
Thomas Haller
682d2c842a core: drop redundant "gateway" variable for NMIPConfig
The "gateway" variable was redundant to best_default_route. It was
somewhat convenient to have, because the best_default_route pointer
might change, but the next hop might still be the same. So it was easy
to track whether it changes.

But it's also redundant information. By relying on best_default_route
alone we have all the information we need.
2021-11-18 16:21:32 +01:00
Beniamino Galvani
8f8e912e3b core: also export 0.0.0.0 as gateway in IP configuration
The IP configuration exported over D-Bus for a device has a "gateway"
property. If the device has a default route without a gateway, before
the L3 rework the gateway used to be exported as "0.0.0.0". That seems
useful to indicate that the device has a default route, but without
a next hop. Restore that behavior.

Fixes-test: @preserve_route_to_generic_device
2021-11-18 16:21:32 +01:00
Thomas Haller
58287cbcc0 core: rework IP configuration in NetworkManager using layer 3 configuration
Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3
manager for the IP configuration of an interface. Use NML3ConfigData as
pieces of configuration that the various components collect and
configure. NMDevice is managing most of the IP configuration at a higher
level, that is, it starts DHCP and other IP methods. Rework the state
handling there.

This is a huge rework of how NetworkManager daemon handles IP
configuration. Some fallout is to be expected.

It appears the patch deletes many lines of code. That is not accurate, because
you also have to count the files `src/core/nm-l3*`, which were unused previously.

Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-11-18 16:21:29 +01:00
Thomas Haller
ac1a9e03e4
all: move "src/" directory to "src/core/"
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.

Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.

We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.

As the name "src/" is already taken, that prevents any sensible
restructuring of the code.

As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".

For inspiration, look at systemd's "src/" directory.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
2021-02-04 09:45:55 +01:00
Renamed from src/nm-ip-config.h (Browse further)