Default-routes are for the most part like regular routes. Add support to track them like regular routes in NMIP4Config/NMIP6Config. One thing is, sometimes we need to figure out whether an ip-config instance has a default-route. For that, keep track of the best default-route (there might be multiple) and expose it. That is the most complicated part of this patch, because there are so many places where the list of routes gets modified (replace, intersect, subtract, merge, add), and they all need to take care of updating the best default-route. In a next patch, NMDefaultRouteManager will be dropped and default-routes will be tracked by NMIP4Config/NMIP6Config.
Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
Eventually, every NMPlatformIP4Route, NMPlatformIP6Route, NMPlatformIP4Address and NMPlatformIP6Address should be shared an deduplicated via the global NMDedupMultiIndex instance. As first proof of concept, refactor NMIP4Config to track IPv4 routes via the shared multi_idx. There is later potential for improvement, when we pass (deduplicated) NMPObject instances around instead of plain NMPlatformIP4Route, which needs still a lot of comparing and cloning.
- config->removed can be replaced by c_list_is_empty(&config->lst) - downgrade some assertions to nm_assert(). Even without the assert we crash a few lines later with a NULL pointer access. That gives almost the same debuggability and discoverability of the bug. - use exact type signature for GAsyncReadyCallback and avoid casting. - when the name owner disappears, cancel all asynchronous operations. Note how the new pacrunner instance will anyway start without configuration, so for all intended purpose, all pending operations are at that moment obsolete.
We must not cancel pacrunner_cancellable when the D-Bus proxy is created. Instead, keep it around and use it later for the asynchronous D-Bus operations. This doesn't really matter at the moment, because the pacrunner manager is only destroyed when NetworkManager is about to terminated. That is the only time when we actually cancel the asynchronous request. Also, at that time we no longer iterate the mainloop, so the pending requests are never completed anyway.
Fixes: e895beb0da38fc87ce93fe7403a6b50e92f0dd82
As NMDevice now creates the NMPacrunnerManager instance as needed, it is even more likely that the initial call to nm_pacrunner_manager_send() will only queue (but not yet send) the new config. Later, when the D-Bus proxy is created, we will not get a name-owner changed signal. We instead have to push the configuration right away. (cherry picked from commit 019b9fbfc0aa2123d1e0a742c0b3d01caaa7d874)
Give logging lines that are concerned with a certain "config" the same prefix: their call-id. (cherry picked from commit 8c81a4b58b17283596b0dcb45825890dd6722ac9)
nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374 (cherry picked from commit b04a9c90eb0a866f2d730cc4777b4f670220ddc7)