2019-09-10 11:19:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2018-05-15 16:47:13 +02:00
|
|
|
* Copyright (C) 2015 - 2018 Red Hat, Inc.
|
2015-04-14 22:34:01 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __NMP_OBJECT_H__
|
|
|
|
|
#define __NMP_OBJECT_H__
|
|
|
|
|
|
2018-12-24 00:41:01 +01:00
|
|
|
#include <netinet/in.h>
|
|
|
|
|
|
2019-04-15 08:16:00 +02:00
|
|
|
#include "nm-glib-aux/nm-obj.h"
|
|
|
|
|
#include "nm-glib-aux/nm-dedup-multi.h"
|
2016-02-12 14:44:52 +01:00
|
|
|
#include "nm-platform.h"
|
2015-04-14 22:34:01 +02:00
|
|
|
|
2017-03-12 15:54:02 +01:00
|
|
|
struct udev_device;
|
|
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2019-03-01 09:32:45 +01:00
|
|
|
/* "struct __kernel_timespec" uses "long long", but we use gint64. In practice,
|
|
|
|
|
* these are the same types. */
|
|
|
|
|
G_STATIC_ASSERT (sizeof (long long) == sizeof (gint64));
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
/* like "struct __kernel_timespec". */
|
|
|
|
|
gint64 tv_sec;
|
|
|
|
|
gint64 tv_nsec;
|
|
|
|
|
} NMPTimespec64;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2018-12-24 00:41:01 +01:00
|
|
|
typedef union {
|
|
|
|
|
struct sockaddr sa;
|
|
|
|
|
struct sockaddr_in in;
|
|
|
|
|
struct sockaddr_in6 in6;
|
|
|
|
|
} NMSockAddrUnion;
|
|
|
|
|
|
2019-01-13 09:46:19 +01:00
|
|
|
#define NM_SOCK_ADDR_UNION_INIT_UNSPEC \
|
|
|
|
|
{ \
|
|
|
|
|
.sa = { \
|
|
|
|
|
.sa_family = AF_UNSPEC, \
|
|
|
|
|
}, \
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int nm_sock_addr_union_cmp (const NMSockAddrUnion *a,
|
|
|
|
|
const NMSockAddrUnion *b);
|
|
|
|
|
|
|
|
|
|
void nm_sock_addr_union_hash_update (const NMSockAddrUnion *a,
|
|
|
|
|
NMHashState *h);
|
|
|
|
|
|
|
|
|
|
void nm_sock_addr_union_cpy (NMSockAddrUnion *dst,
|
|
|
|
|
gconstpointer src /* unaligned (const NMSockAddrUnion *) */);
|
|
|
|
|
|
|
|
|
|
void nm_sock_addr_union_cpy_untrusted (NMSockAddrUnion *dst,
|
|
|
|
|
gconstpointer src /* unaligned (const NMSockAddrUnion *) */,
|
|
|
|
|
gsize src_len);
|
|
|
|
|
|
2019-01-13 11:36:59 +01:00
|
|
|
const char *nm_sock_addr_union_to_string (const NMSockAddrUnion *sa,
|
|
|
|
|
char *buf,
|
|
|
|
|
gsize len);
|
|
|
|
|
|
2019-01-13 09:46:19 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMIPAddr addr;
|
|
|
|
|
guint8 family;
|
|
|
|
|
guint8 mask;
|
|
|
|
|
} NMPWireGuardAllowedIP;
|
|
|
|
|
|
|
|
|
|
typedef struct _NMPWireGuardPeer {
|
2018-12-24 00:41:01 +01:00
|
|
|
NMSockAddrUnion endpoint;
|
2018-12-25 18:41:28 +01:00
|
|
|
|
2019-03-01 09:32:45 +01:00
|
|
|
NMPTimespec64 last_handshake_time;
|
|
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
guint64 rx_bytes;
|
|
|
|
|
guint64 tx_bytes;
|
2018-12-25 18:41:28 +01:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
union {
|
|
|
|
|
const NMPWireGuardAllowedIP *allowed_ips;
|
|
|
|
|
guint _construct_idx_start;
|
|
|
|
|
};
|
|
|
|
|
union {
|
|
|
|
|
guint allowed_ips_len;
|
|
|
|
|
guint _construct_idx_end;
|
|
|
|
|
};
|
2018-12-25 18:41:28 +01:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
guint16 persistent_keepalive_interval;
|
2018-12-25 18:41:28 +01:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
guint8 public_key[NMP_WIREGUARD_PUBLIC_KEY_LEN];
|
|
|
|
|
guint8 preshared_key[NMP_WIREGUARD_SYMMETRIC_KEY_LEN];
|
|
|
|
|
} NMPWireGuardPeer;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
typedef enum { /*< skip >*/
|
|
|
|
|
NMP_OBJECT_TO_STRING_ID,
|
|
|
|
|
NMP_OBJECT_TO_STRING_PUBLIC,
|
|
|
|
|
NMP_OBJECT_TO_STRING_ALL,
|
|
|
|
|
} NMPObjectToStringMode;
|
|
|
|
|
|
|
|
|
|
typedef enum { /*< skip >*/
|
|
|
|
|
NMP_CACHE_OPS_UNCHANGED = NM_PLATFORM_SIGNAL_NONE,
|
|
|
|
|
NMP_CACHE_OPS_ADDED = NM_PLATFORM_SIGNAL_ADDED,
|
2017-11-16 11:58:17 +01:00
|
|
|
NMP_CACHE_OPS_UPDATED = NM_PLATFORM_SIGNAL_CHANGED,
|
2015-04-14 23:14:06 +02:00
|
|
|
NMP_CACHE_OPS_REMOVED = NM_PLATFORM_SIGNAL_REMOVED,
|
|
|
|
|
} NMPCacheOpsType;
|
|
|
|
|
|
|
|
|
|
/* The NMPCacheIdType are the different index types.
|
|
|
|
|
*
|
|
|
|
|
* An object of a certain object-type, can be candidate to being
|
|
|
|
|
* indexed by a certain NMPCacheIdType or not. For example, all
|
|
|
|
|
* objects are indexed via an index of type NMP_CACHE_ID_TYPE_OBJECT_TYPE,
|
2015-06-18 11:44:36 +02:00
|
|
|
* but only route objects can be indexed by NMP_CACHE_ID_TYPE_ROUTES_VISIBLE_NO_DEFAULT.
|
2015-04-14 23:14:06 +02:00
|
|
|
*
|
2015-06-18 11:44:36 +02:00
|
|
|
* Of one index type, there can be multiple indexes or not.
|
2017-11-23 15:41:57 +01:00
|
|
|
* For example, of the index type NMP_CACHE_ID_TYPE_OBJECT_BY_IFINDEX there
|
2015-06-18 11:44:36 +02:00
|
|
|
* are multiple instances (for different route/addresses, v4/v6, per-ifindex).
|
2015-04-14 23:14:06 +02:00
|
|
|
*
|
2015-06-18 11:44:36 +02:00
|
|
|
* But one object, can only be indexed by one particular index of a
|
2015-04-14 23:14:06 +02:00
|
|
|
* type. For example, a certain address instance is only indexed by
|
2017-11-23 15:41:57 +01:00
|
|
|
* the index NMP_CACHE_ID_TYPE_OBJECT_BY_IFINDEX with
|
2015-06-18 11:44:36 +02:00
|
|
|
* matching v4/v6 and ifindex -- or maybe not at all if it isn't visible.
|
2015-04-14 23:14:06 +02:00
|
|
|
* */
|
|
|
|
|
typedef enum { /*< skip >*/
|
2016-04-05 18:59:38 +02:00
|
|
|
NMP_CACHE_ID_TYPE_NONE,
|
|
|
|
|
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
/* all the objects of a certain type.
|
|
|
|
|
*
|
|
|
|
|
* This index is special. It is the only one that contains *all* object.
|
|
|
|
|
* Other indexes may consider some object as non "partitionable", hence
|
|
|
|
|
* they don't track all objects.
|
|
|
|
|
*
|
|
|
|
|
* Hence, this index type is used when looking at all objects (still
|
2017-07-04 11:44:27 +02:00
|
|
|
* partitioned by type).
|
|
|
|
|
*
|
|
|
|
|
* Also, note that links may be considered invisible. This index type
|
|
|
|
|
* expose all links, even invisible ones. For addresses/routes, this
|
2018-09-14 23:49:20 -04:00
|
|
|
* distinction doesn't exist, as all addresses/routes that are alive
|
2017-07-04 11:44:27 +02:00
|
|
|
* are visible as well. */
|
2015-04-14 23:14:06 +02:00
|
|
|
NMP_CACHE_ID_TYPE_OBJECT_TYPE,
|
|
|
|
|
|
2015-12-15 16:23:05 +01:00
|
|
|
/* index for the link objects by ifname. */
|
|
|
|
|
NMP_CACHE_ID_TYPE_LINK_BY_IFNAME,
|
|
|
|
|
|
2018-09-14 23:49:20 -04:00
|
|
|
/* indices for the visible default-routes, ignoring ifindex.
|
2017-07-04 10:55:19 +02:00
|
|
|
* This index only contains two partitions: all visible default-routes,
|
|
|
|
|
* separate for IPv4 and IPv6. */
|
2017-07-04 12:05:07 +02:00
|
|
|
NMP_CACHE_ID_TYPE_DEFAULT_ROUTES,
|
2015-04-14 23:14:06 +02:00
|
|
|
|
2017-11-23 15:41:57 +01:00
|
|
|
/* all the objects that have an ifindex (by object-type) for an ifindex. */
|
|
|
|
|
NMP_CACHE_ID_TYPE_OBJECT_BY_IFINDEX,
|
2015-06-18 11:44:36 +02:00
|
|
|
|
2016-04-10 11:21:50 +02:00
|
|
|
/* Consider all the destination fields of a route, that is, the ID without the ifindex
|
|
|
|
|
* and gateway (meaning: network/plen,metric).
|
|
|
|
|
* The reason for this is that `ip route change` can replace an existing route
|
2018-04-18 14:13:28 +02:00
|
|
|
* and modify its ifindex/gateway. Effectively, that means it deletes an existing
|
2016-04-10 11:21:50 +02:00
|
|
|
* route and adds a different one (as the ID of the route changes). However, it only
|
|
|
|
|
* sends one RTM_NEWADDR notification without notifying about the deletion. We detect
|
|
|
|
|
* that by having this index to contain overlapping routes which require special
|
|
|
|
|
* cache-resync. */
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
NMP_CACHE_ID_TYPE_ROUTES_BY_WEAK_ID,
|
2016-04-10 11:21:50 +02:00
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
/* a filter for objects that track an explicit address family.
|
|
|
|
|
*
|
|
|
|
|
* Note that currently on NMPObjectRoutingRule is indexed by this filter. */
|
|
|
|
|
NMP_CACHE_ID_TYPE_OBJECT_BY_ADDR_FAMILY,
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
__NMP_CACHE_ID_TYPE_MAX,
|
|
|
|
|
NMP_CACHE_ID_TYPE_MAX = __NMP_CACHE_ID_TYPE_MAX - 1,
|
|
|
|
|
} NMPCacheIdType;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
2017-06-12 18:39:53 +02:00
|
|
|
NMDedupMultiObjClass parent;
|
all: add base object type in "nm-obj.h"
Platform has it's own, simple implementation of object types:
NMPObject. Extract a base type and move it to "shared/nm-utils/nm-obj.h"
so it can be reused.
The base type is trival, but it allows us to implement other objects
which are compatible with NMPObjects. Currently there is no API for generic
NMObjBaseInst type, so compatible in this case only means, that they
can be used in the same context (see example below).
The only thing that you can do with a NMObjBaseInst is check it's
NMObjBaseClass.
Incidentally, NMObjBaseInst is also made compatible to GTypeInstance.
It means, an NMObjBaseInst is not necessarily a valid GTypeInstance (like NMPObject
is not), but it could be implemented as such.
For example, you could do:
if (NMP_CLASS_IS_VALID ((NMPClass *) obj->klass)) {
/* is an NMPObject */
} else if (G_TYPE_CHECK_INSTANCE_TYPE (obj, NM_TYPE_SOMETHING)) {
/* it a NMSometing GType */
} else {
/* something else? */
}
The reason why NMPObject is not implemented as proper GTypeInstance is
because it would require us to register a GType (like
g_type_register_fundamental). However, then the NMPClass struct can
no longer be const and immutable memory. But we could.
NMObjBaseInst may or may not be a GTypeInstance. In a sense, it's
a base type of GTypeInstance and all our objects should be based
on it (optionally, they we may make them valid GTypes too).
2017-06-04 20:45:23 +02:00
|
|
|
const char *obj_type_name;
|
|
|
|
|
int sizeof_data;
|
|
|
|
|
int sizeof_public;
|
2015-06-19 16:24:18 +02:00
|
|
|
NMPObjectType obj_type;
|
2015-04-14 23:14:06 +02:00
|
|
|
int addr_family;
|
|
|
|
|
int rtm_gettype;
|
2015-11-27 12:54:31 +01:00
|
|
|
NMPlatformSignalIdType signal_type_id;
|
2015-04-14 23:14:06 +02:00
|
|
|
const char *signal_type;
|
|
|
|
|
|
2016-04-05 18:59:38 +02:00
|
|
|
const guint8 *supported_cache_ids;
|
|
|
|
|
|
2015-10-29 11:27:55 +01:00
|
|
|
/* Only for NMPObjectLnk* types. */
|
|
|
|
|
NMLinkType lnk_link_type;
|
|
|
|
|
|
2017-10-17 11:53:08 +02:00
|
|
|
void (*cmd_obj_hash_update) (const NMPObject *obj, NMHashState *h);
|
2015-10-12 13:19:10 +02:00
|
|
|
int (*cmd_obj_cmp) (const NMPObject *obj1, const NMPObject *obj2);
|
2015-04-14 23:14:06 +02:00
|
|
|
void (*cmd_obj_copy) (NMPObject *dst, const NMPObject *src);
|
|
|
|
|
void (*cmd_obj_dispose) (NMPObject *obj);
|
|
|
|
|
gboolean (*cmd_obj_is_alive) (const NMPObject *obj);
|
|
|
|
|
gboolean (*cmd_obj_is_visible) (const NMPObject *obj);
|
2015-10-27 18:30:20 +01:00
|
|
|
const char *(*cmd_obj_to_string) (const NMPObject *obj, NMPObjectToStringMode to_string_mode, char *buf, gsize buf_size);
|
2015-04-14 23:14:06 +02:00
|
|
|
|
|
|
|
|
/* functions that operate on NMPlatformObject */
|
|
|
|
|
void (*cmd_plobj_id_copy) (NMPlatformObject *dst, const NMPlatformObject *src);
|
2017-08-12 15:55:17 +02:00
|
|
|
int (*cmd_plobj_id_cmp) (const NMPlatformObject *obj1, const NMPlatformObject *obj2);
|
2017-10-17 11:53:08 +02:00
|
|
|
void (*cmd_plobj_id_hash_update) (const NMPlatformObject *obj, NMHashState *h);
|
2015-04-14 23:14:06 +02:00
|
|
|
const char *(*cmd_plobj_to_string_id) (const NMPlatformObject *obj, char *buf, gsize buf_size);
|
2015-10-12 10:27:33 +02:00
|
|
|
const char *(*cmd_plobj_to_string) (const NMPlatformObject *obj, char *buf, gsize len);
|
2017-10-17 11:53:08 +02:00
|
|
|
void (*cmd_plobj_hash_update) (const NMPlatformObject *obj, NMHashState *h);
|
2015-04-14 23:14:06 +02:00
|
|
|
int (*cmd_plobj_cmp) (const NMPlatformObject *obj1, const NMPlatformObject *obj2);
|
|
|
|
|
} NMPClass;
|
|
|
|
|
|
2015-06-24 15:29:01 +02:00
|
|
|
extern const NMPClass _nmp_classes[NMP_OBJECT_TYPE_MAX];
|
2015-04-14 23:14:06 +02:00
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLink _public;
|
|
|
|
|
|
|
|
|
|
struct {
|
2015-11-20 12:01:46 +01:00
|
|
|
bool is_in_netlink;
|
2015-10-12 12:41:42 +02:00
|
|
|
|
|
|
|
|
/* Additional data that depends on the link-type (IFLA_INFO_DATA) */
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
const NMPObject *lnk;
|
2015-04-14 23:14:06 +02:00
|
|
|
} netlink;
|
|
|
|
|
|
|
|
|
|
struct {
|
2017-03-12 15:54:02 +01:00
|
|
|
/* note that "struct udev_device" references the library context
|
|
|
|
|
* "struct udev", but doesn't own it.
|
|
|
|
|
*
|
|
|
|
|
* Hence, the udev.device shall not be used after the library
|
2020-07-04 11:37:01 +03:00
|
|
|
* context is destroyed.
|
2017-03-12 15:54:02 +01:00
|
|
|
*
|
|
|
|
|
* In case of NMPObjectLink instances that you obtained from the
|
|
|
|
|
* platform cache, that means that you shall no keep references
|
|
|
|
|
* to those instances that outlife the NMPlatform instance.
|
|
|
|
|
*
|
|
|
|
|
* In practice, the requirement is less strict and you'll be even
|
|
|
|
|
* fine if the platform instance (and the "struct udev" instance)
|
|
|
|
|
* are already destroyed while you still hold onto a reference to
|
|
|
|
|
* the NMPObjectLink instance. Just don't make use of udev functions
|
|
|
|
|
* that cause access to the udev library context.
|
|
|
|
|
*/
|
|
|
|
|
struct udev_device *device;
|
2015-04-14 23:14:06 +02:00
|
|
|
} udev;
|
2018-05-15 16:47:13 +02:00
|
|
|
|
2018-06-05 15:20:54 +02:00
|
|
|
/* Auxiliary data object for Wi-Fi and WPAN */
|
|
|
|
|
GObject *ext_data;
|
2018-07-01 15:13:25 +02:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
/* FIXME: not every NMPObjectLink should pay the price for tracking
|
|
|
|
|
* the wireguard family id. This should be tracked via ext_data, which
|
|
|
|
|
* would be exactly the right place. */
|
2018-07-01 15:13:25 +02:00
|
|
|
int wireguard_family_id;
|
2015-04-14 23:14:06 +02:00
|
|
|
} NMPObjectLink;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkGre _public;
|
|
|
|
|
} NMPObjectLnkGre;
|
|
|
|
|
|
2015-10-15 15:47:14 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkInfiniband _public;
|
|
|
|
|
} NMPObjectLnkInfiniband;
|
|
|
|
|
|
2015-11-27 22:22:25 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkIp6Tnl _public;
|
|
|
|
|
} NMPObjectLnkIp6Tnl;
|
|
|
|
|
|
2015-11-27 14:01:56 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkIpIp _public;
|
|
|
|
|
} NMPObjectLnkIpIp;
|
|
|
|
|
|
2016-06-30 18:20:09 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkMacsec _public;
|
|
|
|
|
} NMPObjectLnkMacsec;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkMacvlan _public;
|
|
|
|
|
} NMPObjectLnkMacvlan;
|
|
|
|
|
|
2015-12-04 09:49:39 +01:00
|
|
|
typedef NMPObjectLnkMacvlan NMPObjectLnkMacvtap;
|
|
|
|
|
|
2015-11-11 18:41:48 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkSit _public;
|
|
|
|
|
} NMPObjectLnkSit;
|
|
|
|
|
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkTun _public;
|
|
|
|
|
} NMPObjectLnkTun;
|
|
|
|
|
|
2015-10-12 13:44:44 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkVlan _public;
|
2015-10-27 16:14:54 +01:00
|
|
|
|
|
|
|
|
guint n_ingress_qos_map;
|
|
|
|
|
guint n_egress_qos_map;
|
|
|
|
|
const NMVlanQosMapping *ingress_qos_map;
|
|
|
|
|
const NMVlanQosMapping *egress_qos_map;
|
2015-10-12 13:44:44 +02:00
|
|
|
} NMPObjectLnkVlan;
|
|
|
|
|
|
2019-12-05 10:35:25 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkVrf _public;
|
|
|
|
|
} NMPObjectLnkVrf;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformLnkVxlan _public;
|
|
|
|
|
} NMPObjectLnkVxlan;
|
|
|
|
|
|
2018-03-13 13:35:35 +00:00
|
|
|
typedef struct {
|
2018-07-28 14:54:33 +02:00
|
|
|
NMPlatformLnkWireGuard _public;
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
const NMPWireGuardPeer *peers;
|
|
|
|
|
const NMPWireGuardAllowedIP *_allowed_ips_buf;
|
|
|
|
|
guint peers_len;
|
|
|
|
|
guint _allowed_ips_buf_len;
|
2018-07-28 14:54:33 +02:00
|
|
|
} NMPObjectLnkWireGuard;
|
2018-03-13 13:35:35 +00:00
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformIP4Address _public;
|
|
|
|
|
} NMPObjectIP4Address;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformIP4Route _public;
|
|
|
|
|
} NMPObjectIP4Route;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformIP6Address _public;
|
|
|
|
|
} NMPObjectIP6Address;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformIP6Route _public;
|
|
|
|
|
} NMPObjectIP6Route;
|
|
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformRoutingRule _public;
|
|
|
|
|
} NMPObjectRoutingRule;
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformQdisc _public;
|
|
|
|
|
} NMPObjectQdisc;
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
|
|
|
|
NMPlatformTfilter _public;
|
|
|
|
|
} NMPObjectTfilter;
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
struct _NMPObject {
|
all: add base object type in "nm-obj.h"
Platform has it's own, simple implementation of object types:
NMPObject. Extract a base type and move it to "shared/nm-utils/nm-obj.h"
so it can be reused.
The base type is trival, but it allows us to implement other objects
which are compatible with NMPObjects. Currently there is no API for generic
NMObjBaseInst type, so compatible in this case only means, that they
can be used in the same context (see example below).
The only thing that you can do with a NMObjBaseInst is check it's
NMObjBaseClass.
Incidentally, NMObjBaseInst is also made compatible to GTypeInstance.
It means, an NMObjBaseInst is not necessarily a valid GTypeInstance (like NMPObject
is not), but it could be implemented as such.
For example, you could do:
if (NMP_CLASS_IS_VALID ((NMPClass *) obj->klass)) {
/* is an NMPObject */
} else if (G_TYPE_CHECK_INSTANCE_TYPE (obj, NM_TYPE_SOMETHING)) {
/* it a NMSometing GType */
} else {
/* something else? */
}
The reason why NMPObject is not implemented as proper GTypeInstance is
because it would require us to register a GType (like
g_type_register_fundamental). However, then the NMPClass struct can
no longer be const and immutable memory. But we could.
NMObjBaseInst may or may not be a GTypeInstance. In a sense, it's
a base type of GTypeInstance and all our objects should be based
on it (optionally, they we may make them valid GTypes too).
2017-06-04 20:45:23 +02:00
|
|
|
union {
|
2017-06-12 18:39:53 +02:00
|
|
|
NMDedupMultiObj parent;
|
all: add base object type in "nm-obj.h"
Platform has it's own, simple implementation of object types:
NMPObject. Extract a base type and move it to "shared/nm-utils/nm-obj.h"
so it can be reused.
The base type is trival, but it allows us to implement other objects
which are compatible with NMPObjects. Currently there is no API for generic
NMObjBaseInst type, so compatible in this case only means, that they
can be used in the same context (see example below).
The only thing that you can do with a NMObjBaseInst is check it's
NMObjBaseClass.
Incidentally, NMObjBaseInst is also made compatible to GTypeInstance.
It means, an NMObjBaseInst is not necessarily a valid GTypeInstance (like NMPObject
is not), but it could be implemented as such.
For example, you could do:
if (NMP_CLASS_IS_VALID ((NMPClass *) obj->klass)) {
/* is an NMPObject */
} else if (G_TYPE_CHECK_INSTANCE_TYPE (obj, NM_TYPE_SOMETHING)) {
/* it a NMSometing GType */
} else {
/* something else? */
}
The reason why NMPObject is not implemented as proper GTypeInstance is
because it would require us to register a GType (like
g_type_register_fundamental). However, then the NMPClass struct can
no longer be const and immutable memory. But we could.
NMObjBaseInst may or may not be a GTypeInstance. In a sense, it's
a base type of GTypeInstance and all our objects should be based
on it (optionally, they we may make them valid GTypes too).
2017-06-04 20:45:23 +02:00
|
|
|
const NMPClass *_class;
|
|
|
|
|
};
|
2015-04-14 23:14:06 +02:00
|
|
|
union {
|
|
|
|
|
NMPlatformObject object;
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
NMPlatformObjWithIfindex obj_with_ifindex;
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
NMPlatformLink link;
|
|
|
|
|
NMPObjectLink _link;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
NMPlatformLnkGre lnk_gre;
|
|
|
|
|
NMPObjectLnkGre _lnk_gre;
|
|
|
|
|
|
2015-10-15 15:47:14 +02:00
|
|
|
NMPlatformLnkInfiniband lnk_infiniband;
|
|
|
|
|
NMPObjectLnkInfiniband _lnk_infiniband;
|
|
|
|
|
|
2015-11-27 14:01:56 +01:00
|
|
|
NMPlatformLnkIpIp lnk_ipip;
|
|
|
|
|
NMPObjectLnkIpIp _lnk_ipip;
|
|
|
|
|
|
2015-11-27 22:22:25 +01:00
|
|
|
NMPlatformLnkIp6Tnl lnk_ip6tnl;
|
|
|
|
|
NMPObjectLnkIp6Tnl _lnk_ip6tnl;
|
|
|
|
|
|
2016-06-30 18:20:09 +02:00
|
|
|
NMPlatformLnkMacsec lnk_macsec;
|
|
|
|
|
NMPObjectLnkMacsec _lnk_macsec;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
NMPlatformLnkMacvlan lnk_macvlan;
|
|
|
|
|
NMPObjectLnkMacvlan _lnk_macvlan;
|
|
|
|
|
|
2015-11-11 18:41:48 +01:00
|
|
|
NMPlatformLnkSit lnk_sit;
|
|
|
|
|
NMPObjectLnkSit _lnk_sit;
|
|
|
|
|
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
NMPlatformLnkTun lnk_tun;
|
|
|
|
|
NMPObjectLnkTun _lnk_tun;
|
|
|
|
|
|
2015-10-12 13:44:44 +02:00
|
|
|
NMPlatformLnkVlan lnk_vlan;
|
|
|
|
|
NMPObjectLnkVlan _lnk_vlan;
|
|
|
|
|
|
2019-12-05 10:35:25 +01:00
|
|
|
NMPlatformLnkVrf lnk_vrf;
|
|
|
|
|
NMPObjectLnkVrf _lnk_vrf;
|
|
|
|
|
|
2015-10-12 15:15:21 +02:00
|
|
|
NMPlatformLnkVxlan lnk_vxlan;
|
|
|
|
|
NMPObjectLnkVxlan _lnk_vxlan;
|
|
|
|
|
|
2018-07-28 14:54:33 +02:00
|
|
|
NMPlatformLnkWireGuard lnk_wireguard;
|
|
|
|
|
NMPObjectLnkWireGuard _lnk_wireguard;
|
2018-03-13 13:35:35 +00:00
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
NMPlatformIPAddress ip_address;
|
|
|
|
|
NMPlatformIPXAddress ipx_address;
|
|
|
|
|
NMPlatformIP4Address ip4_address;
|
|
|
|
|
NMPlatformIP6Address ip6_address;
|
|
|
|
|
NMPObjectIP4Address _ip4_address;
|
|
|
|
|
NMPObjectIP6Address _ip6_address;
|
|
|
|
|
|
|
|
|
|
NMPlatformIPRoute ip_route;
|
|
|
|
|
NMPlatformIPXRoute ipx_route;
|
|
|
|
|
NMPlatformIP4Route ip4_route;
|
|
|
|
|
NMPlatformIP6Route ip6_route;
|
|
|
|
|
NMPObjectIP4Route _ip4_route;
|
|
|
|
|
NMPObjectIP6Route _ip6_route;
|
2017-11-15 20:36:35 +01:00
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
NMPlatformRoutingRule routing_rule;
|
|
|
|
|
NMPObjectRoutingRule _routing_rule;
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
NMPlatformQdisc qdisc;
|
|
|
|
|
NMPObjectQdisc _qdisc;
|
2017-11-15 20:36:35 +01:00
|
|
|
NMPlatformTfilter tfilter;
|
|
|
|
|
NMPObjectTfilter _tfilter;
|
2015-04-14 23:14:06 +02:00
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2019-03-04 13:50:40 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
NMP_CLASS_IS_VALID (const NMPClass *klass)
|
|
|
|
|
{
|
|
|
|
|
return klass >= &_nmp_classes[0]
|
|
|
|
|
&& klass <= &_nmp_classes[G_N_ELEMENTS (_nmp_classes)]
|
2017-03-09 15:12:05 +01:00
|
|
|
&& ((((char *) klass) - ((char *) _nmp_classes)) % (sizeof (_nmp_classes[0]))) == 0;
|
2015-04-14 23:14:06 +02:00
|
|
|
}
|
|
|
|
|
|
2019-03-04 13:50:40 +01:00
|
|
|
static inline const NMPClass *
|
|
|
|
|
nmp_class_from_type (NMPObjectType obj_type)
|
|
|
|
|
{
|
|
|
|
|
nm_assert (obj_type > 0);
|
|
|
|
|
nm_assert (obj_type <= G_N_ELEMENTS (_nmp_classes));
|
|
|
|
|
nm_assert (_nmp_classes[obj_type - 1].obj_type == obj_type);
|
|
|
|
|
nm_assert (NMP_CLASS_IS_VALID (&_nmp_classes[obj_type - 1]));
|
|
|
|
|
|
|
|
|
|
return &_nmp_classes[obj_type - 1];
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
static inline NMPObject *
|
|
|
|
|
NMP_OBJECT_UP_CAST(const NMPlatformObject *plobj)
|
|
|
|
|
{
|
|
|
|
|
NMPObject *obj;
|
|
|
|
|
|
|
|
|
|
obj = plobj
|
|
|
|
|
? (NMPObject *) ( &(((char *) plobj)[-((int) G_STRUCT_OFFSET (NMPObject, object))]) )
|
|
|
|
|
: NULL;
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
nm_assert (!obj || (obj->parent._ref_count > 0 && NMP_CLASS_IS_VALID (obj->_class)));
|
2015-04-14 23:14:06 +02:00
|
|
|
return obj;
|
|
|
|
|
}
|
|
|
|
|
#define NMP_OBJECT_UP_CAST(plobj) (NMP_OBJECT_UP_CAST ((const NMPlatformObject *) (plobj)))
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
NMP_OBJECT_IS_VALID (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
nm_assert (!obj || ( obj
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
&& obj->parent._ref_count > 0
|
2015-04-14 23:14:06 +02:00
|
|
|
&& NMP_CLASS_IS_VALID (obj->_class)));
|
|
|
|
|
|
|
|
|
|
/* There isn't really much to check. Either @obj is NULL, or we must
|
|
|
|
|
* assume that it points to valid memory. */
|
|
|
|
|
return obj != NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
NMP_OBJECT_IS_STACKINIT (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
nm_assert (!obj || NMP_OBJECT_IS_VALID (obj));
|
|
|
|
|
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
return obj && obj->parent._ref_count == NM_OBJ_REF_COUNT_STACKINIT;
|
2015-04-14 23:14:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const NMPClass *
|
|
|
|
|
NMP_OBJECT_GET_CLASS (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
nm_assert (NMP_OBJECT_IS_VALID (obj));
|
|
|
|
|
|
|
|
|
|
return obj->_class;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-19 16:24:18 +02:00
|
|
|
static inline NMPObjectType
|
2015-04-14 23:14:06 +02:00
|
|
|
NMP_OBJECT_GET_TYPE (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
nm_assert (!obj || NMP_OBJECT_IS_VALID (obj));
|
|
|
|
|
|
2015-06-24 15:29:01 +02:00
|
|
|
return obj ? obj->_class->obj_type : NMP_OBJECT_TYPE_UNKNOWN;
|
2015-04-14 23:14:06 +02:00
|
|
|
}
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
static inline gboolean
|
|
|
|
|
_NMP_OBJECT_TYPE_IS_OBJ_WITH_IFINDEX (NMPObjectType obj_type)
|
|
|
|
|
{
|
|
|
|
|
switch (obj_type) {
|
|
|
|
|
case NMP_OBJECT_TYPE_LINK:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP4_ADDRESS:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP6_ADDRESS:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP4_ROUTE:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP6_ROUTE:
|
|
|
|
|
|
|
|
|
|
case NMP_OBJECT_TYPE_QDISC:
|
|
|
|
|
|
|
|
|
|
case NMP_OBJECT_TYPE_TFILTER:
|
|
|
|
|
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_GRE:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_GRETAP:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_INFINIBAND:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_IP6TNL:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_IP6GRE:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_IP6GRETAP:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_IPIP:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_MACSEC:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_MACVLAN:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_MACVTAP:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_SIT:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_TUN:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_VLAN:
|
2020-02-22 12:09:35 +01:00
|
|
|
case NMP_OBJECT_TYPE_LNK_VRF:
|
2019-03-04 13:01:21 +01:00
|
|
|
case NMP_OBJECT_TYPE_LNK_VXLAN:
|
|
|
|
|
case NMP_OBJECT_TYPE_LNK_WIREGUARD:
|
|
|
|
|
return TRUE;
|
2020-02-22 12:07:01 +01:00
|
|
|
|
|
|
|
|
case NMP_OBJECT_TYPE_ROUTING_RULE:
|
2019-03-04 13:01:21 +01:00
|
|
|
return FALSE;
|
2020-02-22 12:07:01 +01:00
|
|
|
|
|
|
|
|
case NMP_OBJECT_TYPE_UNKNOWN:
|
|
|
|
|
case __NMP_OBJECT_TYPE_LAST:
|
|
|
|
|
break;
|
2019-03-04 13:01:21 +01:00
|
|
|
}
|
2020-02-22 12:07:01 +01:00
|
|
|
nm_assert_not_reached ();
|
|
|
|
|
return FALSE;
|
2019-03-04 13:01:21 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define NMP_OBJECT_CAST_OBJECT(obj) \
|
|
|
|
|
({ \
|
|
|
|
|
typeof (obj) _obj = (obj); \
|
|
|
|
|
\
|
|
|
|
|
nm_assert ( !_obj \
|
|
|
|
|
|| nmp_class_from_type (NMP_OBJECT_GET_TYPE (_obj)))); \
|
|
|
|
|
_obj ? &NM_CONSTCAST (NMPObject, _obj)->object : NULL; \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
#define NMP_OBJECT_CAST_OBJ_WITH_IFINDEX(obj) \
|
|
|
|
|
({ \
|
|
|
|
|
typeof (obj) _obj = (obj); \
|
|
|
|
|
\
|
|
|
|
|
nm_assert ( !_obj \
|
|
|
|
|
|| _NMP_OBJECT_TYPE_IS_OBJ_WITH_IFINDEX (NMP_OBJECT_GET_TYPE (_obj))); \
|
|
|
|
|
_obj ? &NM_CONSTCAST (NMPObject, _obj)->obj_with_ifindex : NULL; \
|
|
|
|
|
})
|
|
|
|
|
|
2019-07-28 14:16:37 +02:00
|
|
|
#define _NMP_OBJECT_CAST(obj, field, ...) \
|
2017-07-04 12:49:47 +02:00
|
|
|
({ \
|
2017-07-05 11:12:59 +02:00
|
|
|
typeof (obj) _obj = (obj); \
|
2017-07-04 12:49:47 +02:00
|
|
|
\
|
2019-07-28 14:16:37 +02:00
|
|
|
nm_assert (!_obj || NM_IN_SET (NMP_OBJECT_GET_TYPE (_obj), __VA_ARGS__)); \
|
|
|
|
|
_obj ? &NM_CONSTCAST (NMPObject, _obj)->field : NULL; \
|
2017-07-04 12:49:47 +02:00
|
|
|
})
|
|
|
|
|
|
2019-07-28 14:16:37 +02:00
|
|
|
#define NMP_OBJECT_CAST_LINK(obj) _NMP_OBJECT_CAST (obj, link, NMP_OBJECT_TYPE_LINK)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP_ADDRESS(obj) _NMP_OBJECT_CAST (obj, ip_address, NMP_OBJECT_TYPE_IP4_ADDRESS, NMP_OBJECT_TYPE_IP6_ADDRESS)
|
|
|
|
|
#define NMP_OBJECT_CAST_IPX_ADDRESS(obj) _NMP_OBJECT_CAST (obj, ipx_address, NMP_OBJECT_TYPE_IP4_ADDRESS, NMP_OBJECT_TYPE_IP6_ADDRESS)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP4_ADDRESS(obj) _NMP_OBJECT_CAST (obj, ip4_address, NMP_OBJECT_TYPE_IP4_ADDRESS)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP6_ADDRESS(obj) _NMP_OBJECT_CAST (obj, ip6_address, NMP_OBJECT_TYPE_IP6_ADDRESS)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP_ROUTE(obj) _NMP_OBJECT_CAST (obj, ip_route, NMP_OBJECT_TYPE_IP4_ROUTE, NMP_OBJECT_TYPE_IP6_ROUTE)
|
|
|
|
|
#define NMP_OBJECT_CAST_IPX_ROUTE(obj) _NMP_OBJECT_CAST (obj, ipx_route, NMP_OBJECT_TYPE_IP4_ROUTE, NMP_OBJECT_TYPE_IP6_ROUTE)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP4_ROUTE(obj) _NMP_OBJECT_CAST (obj, ip4_route, NMP_OBJECT_TYPE_IP4_ROUTE)
|
|
|
|
|
#define NMP_OBJECT_CAST_IP6_ROUTE(obj) _NMP_OBJECT_CAST (obj, ip6_route, NMP_OBJECT_TYPE_IP6_ROUTE)
|
|
|
|
|
#define NMP_OBJECT_CAST_ROUTING_RULE(obj) _NMP_OBJECT_CAST (obj, routing_rule, NMP_OBJECT_TYPE_ROUTING_RULE)
|
|
|
|
|
#define NMP_OBJECT_CAST_QDISC(obj) _NMP_OBJECT_CAST (obj, qdisc, NMP_OBJECT_TYPE_QDISC)
|
|
|
|
|
#define NMP_OBJECT_CAST_TFILTER(obj) _NMP_OBJECT_CAST (obj, tfilter, NMP_OBJECT_TYPE_TFILTER)
|
2019-07-28 14:20:56 +02:00
|
|
|
#define NMP_OBJECT_CAST_LNK_WIREGUARD(obj) _NMP_OBJECT_CAST (obj, lnk_wireguard, NMP_OBJECT_TYPE_LNK_WIREGUARD)
|
2017-11-15 20:36:35 +01:00
|
|
|
|
2020-07-21 17:35:45 +02:00
|
|
|
static inline int
|
|
|
|
|
NMP_OBJECT_GET_ADDR_FAMILY (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
switch (NMP_OBJECT_GET_TYPE (obj)) {
|
|
|
|
|
case NMP_OBJECT_TYPE_IP4_ADDRESS:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP4_ROUTE:
|
|
|
|
|
return AF_INET;
|
|
|
|
|
case NMP_OBJECT_TYPE_IP6_ADDRESS:
|
|
|
|
|
case NMP_OBJECT_TYPE_IP6_ROUTE:
|
|
|
|
|
return AF_INET6;
|
|
|
|
|
default:
|
|
|
|
|
return AF_UNSPEC;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
static inline const NMPObject *
|
|
|
|
|
nmp_object_ref (const NMPObject *obj)
|
|
|
|
|
{
|
2017-08-05 15:14:44 +02:00
|
|
|
if (!obj) {
|
|
|
|
|
/* for convenience, allow NULL. */
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
/* ref and unref accept const pointers. NMPObject is supposed to be shared
|
2018-09-14 23:49:20 -04:00
|
|
|
* and kept immutable. Disallowing to take/return a reference to a const
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
* NMPObject is cumbersome, because callers are precisely expected to
|
|
|
|
|
* keep a ref on the otherwise immutable object. */
|
|
|
|
|
g_return_val_if_fail (NMP_OBJECT_IS_VALID (obj), NULL);
|
|
|
|
|
g_return_val_if_fail (obj->parent._ref_count != NM_OBJ_REF_COUNT_STACKINIT, NULL);
|
|
|
|
|
|
|
|
|
|
return (const NMPObject *) nm_dedup_multi_obj_ref ((const NMDedupMultiObj *) obj);
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-07 19:27:35 +00:00
|
|
|
static inline void
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
nmp_object_unref (const NMPObject *obj)
|
|
|
|
|
{
|
2019-02-27 16:54:43 +01:00
|
|
|
if (obj) {
|
|
|
|
|
nm_assert (NMP_OBJECT_IS_VALID (obj));
|
2018-03-22 16:49:38 +01:00
|
|
|
|
2019-02-27 16:54:43 +01:00
|
|
|
nm_dedup_multi_obj_unref ((const NMDedupMultiObj *) obj);
|
|
|
|
|
}
|
core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.
With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.
- this saves an additional GSlice allocation for the NMDedupMultiBox.
- it is immediately known, whether an NMPObject is tracked by a
certain NMDedupMultiIndex or not. This saves an additional hash
lookup.
- previously, when all idx-types cease to reference an NMDedupMultiObj
instance, it was removed. Now, a tracked objects stays in the
NMDedupMultiIndex until it's last reference is deleted. This possibly
extends the lifetime of the object and we may reuse it better.
- it is no longer possible to add one object to more then one
NMDedupMultiIndex instance. As we anyway want to have only one
instance to deduplicate the objects, this is fine.
- the ref-counting implementation is now part of NMDedupMultiObj.
Previously, NMDedupMultiIndex could also track objects that were
not ref-counted. Hoever, the object anyway *must* implement the
NMDedupMultiObj API, so this flexibility is unneeded and was not
used.
- a downside is, that NMPObject grows by one pointer size, even if
it isn't tracked in the NMDedupMultiIndex. But we really want to
put all objects into the index for sharing and deduplication. So
this downside should be acceptable. Still, code like
nmp_object_stackinit*() needs to handle a larger object.
2017-07-02 23:46:06 +02:00
|
|
|
}
|
|
|
|
|
|
2017-08-30 19:15:39 +02:00
|
|
|
#define nm_clear_nmp_object(ptr) \
|
|
|
|
|
({ \
|
|
|
|
|
typeof (ptr) _ptr = (ptr); \
|
|
|
|
|
typeof (*_ptr) _pptr; \
|
|
|
|
|
gboolean _changed = FALSE; \
|
|
|
|
|
\
|
|
|
|
|
if ( _ptr \
|
|
|
|
|
&& (_pptr = *_ptr)) { \
|
|
|
|
|
*_ptr = NULL; \
|
|
|
|
|
nmp_object_unref (_pptr); \
|
|
|
|
|
_changed = TRUE; \
|
|
|
|
|
} \
|
|
|
|
|
_changed; \
|
|
|
|
|
})
|
|
|
|
|
|
2020-07-21 17:48:30 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
nmp_object_ref_set (const NMPObject **pp, const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
gboolean _changed = FALSE;
|
|
|
|
|
const NMPObject *p;
|
|
|
|
|
|
|
|
|
|
nm_assert (!pp || !*pp || NMP_OBJECT_IS_VALID (*pp));
|
|
|
|
|
nm_assert (!obj || NMP_OBJECT_IS_VALID (obj));
|
|
|
|
|
|
|
|
|
|
if ( pp
|
|
|
|
|
&& ((p = *pp) != obj)) {
|
|
|
|
|
nmp_object_ref (obj);
|
|
|
|
|
*pp = obj;
|
|
|
|
|
nmp_object_unref (p);
|
|
|
|
|
_changed = TRUE;
|
|
|
|
|
}
|
|
|
|
|
return _changed;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-28 16:06:11 +02:00
|
|
|
NMPObject *nmp_object_new (NMPObjectType obj_type, gconstpointer plobj);
|
2015-04-14 23:14:06 +02:00
|
|
|
NMPObject *nmp_object_new_link (int ifindex);
|
|
|
|
|
|
platform: adding onlink gateway route for manual addresses
Kernel does not all allow to configure a route via a gateway, if the
gateway is not directly reachable.
For non-manually added routes (e.g. from DHCP), we ignore them as a
server configuration errors. For manually added routes, we try to work
around them.
Note that if the user adds a manual route that references a gateway,
maybe he should be required to also add a matching onlink route for
the gateway (or an address that results in a device-route), otherwise
the configuration could be considered invalid. That was however not
done historically, and also, it seems a rather unhelpful behavior.
NetworkManage should just make it work, not not assume anything is
wrong with the configuration. Similarly, for IPv4, the user could
configure the route as onlink, however, that still requires extra
configuration of which the user might not be aware.
This would apply for example, when a connection has method=auto,
and would obtain the routes automatically. It seems sensible to
allow the user to add a route via the gateway, if he ~knows~ that
this particular network will provide such a configuration via DHCP.
In the past however, we tried not to automatically add a device route,
but instead see whether we will get a suitable route via DHCP. If we
wouldn't get such a route, we would however fail the connection.
However, this is really very hard to get right.
We call ip_config_merge_and_apply() possibly before receiving automatic
IP configuration (commit 7070d17cedd09d07f12ce977dd1e16cecf8d4b45, "device: reset
@con_ip6_config on failure before RA"). In this case, we could not yet
configure the route. Instead, we also cannot fail (yet), because we should
wait whether we will receive a route that makes this configuration
feasable.
That is hard to get right. How long should we wait? If we get a DHCP lease
and still cannot add the route, should we fail the IP configuration or wait
longer for another lease? Worse, if we decide to fail the IP configuration,
it might not fail the entire activation. Instead, we would only mark the
current address family as failed. If we later get a DHCP lease, should we
retry to add the route again? -- probably yes. If we still fail, we would
need to keep the IP configuration in failed state, regardless that DHCP
succeeded. Part of the problem is, that we are bad at tracking the
failed state per IP method. So, if manual configuration fails but DHCP
succeeds, we get the state wrong. That should be fixed separately, but it
just shows how hard it is to have this route that we currently cannot
add, and wanting to wait for something that might never come, but still
fail at some point.
Instead, if we cannot add a route due to a missing onlink gateway,
just retry and add the /32 or /128 direct route ourself.
Note that for IPv6 routes that have a "src" address which is still
TENTATIVE, we also cannot currently add the route and retry later.
However, that is fundamentally different, because:
- the configuration here is correct, it's only that the address
didn't yet pass IPv6 DAD and kernel is being unhelpful (rh#1457196).
- we only have to wait a few seconds for DAD to complete or fail.
So, it's easy to implement this sensibly.
2018-03-23 15:44:17 +01:00
|
|
|
const NMPObject *nmp_object_stackinit (NMPObject *obj, NMPObjectType obj_type, gconstpointer plobj);
|
2017-07-07 23:34:41 +02:00
|
|
|
|
|
|
|
|
static inline NMPObject *
|
|
|
|
|
nmp_object_stackinit_obj (NMPObject *obj, const NMPObject *src)
|
|
|
|
|
{
|
|
|
|
|
return obj == src
|
|
|
|
|
? obj
|
|
|
|
|
: (NMPObject *) nmp_object_stackinit (obj, NMP_OBJECT_GET_TYPE (src), &src->object);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
const NMPObject *nmp_object_stackinit_id (NMPObject *obj, const NMPObject *src);
|
|
|
|
|
const NMPObject *nmp_object_stackinit_id_link (NMPObject *obj, int ifindex);
|
2016-04-06 18:04:26 +02:00
|
|
|
const NMPObject *nmp_object_stackinit_id_ip4_address (NMPObject *obj, int ifindex, guint32 address, guint8 plen, guint32 peer_address);
|
2017-05-26 21:49:00 +02:00
|
|
|
const NMPObject *nmp_object_stackinit_id_ip6_address (NMPObject *obj, int ifindex, const struct in6_addr *address);
|
2015-04-14 23:14:06 +02:00
|
|
|
|
|
|
|
|
const char *nmp_object_to_string (const NMPObject *obj, NMPObjectToStringMode to_string_mode, char *buf, gsize buf_size);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nmp_object_hash_update (const NMPObject *obj, NMHashState *h);
|
2015-04-14 23:14:06 +02:00
|
|
|
int nmp_object_cmp (const NMPObject *obj1, const NMPObject *obj2);
|
2017-11-20 12:55:14 +01:00
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nmp_object_equal (const NMPObject *obj1, const NMPObject *obj2)
|
|
|
|
|
{
|
|
|
|
|
return nmp_object_cmp (obj1, obj2) == 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
void nmp_object_copy (NMPObject *dst, const NMPObject *src, gboolean id_only);
|
|
|
|
|
NMPObject *nmp_object_clone (const NMPObject *obj, gboolean id_only);
|
2017-08-12 15:55:17 +02:00
|
|
|
|
|
|
|
|
int nmp_object_id_cmp (const NMPObject *obj1, const NMPObject *obj2);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nmp_object_id_hash_update (const NMPObject *obj, NMHashState *h);
|
2015-04-14 23:14:06 +02:00
|
|
|
guint nmp_object_id_hash (const NMPObject *obj);
|
2017-08-12 15:55:17 +02:00
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nmp_object_id_equal (const NMPObject *obj1, const NMPObject *obj2)
|
|
|
|
|
{
|
|
|
|
|
return nmp_object_id_cmp (obj1, obj2) == 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
gboolean nmp_object_is_alive (const NMPObject *obj);
|
|
|
|
|
gboolean nmp_object_is_visible (const NMPObject *obj);
|
|
|
|
|
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
void _nmp_object_fixup_link_udev_fields (NMPObject **obj_new, NMPObject *obj_orig, gboolean use_udev);
|
2015-04-14 23:14:06 +02:00
|
|
|
|
|
|
|
|
static inline void
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
_nm_auto_nmpobj_cleanup (gpointer p)
|
2015-04-14 23:14:06 +02:00
|
|
|
{
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
nmp_object_unref (*((const NMPObject **) p));
|
2015-04-14 23:14:06 +02:00
|
|
|
}
|
2017-10-11 08:40:14 +02:00
|
|
|
#define nm_auto_nmpobj nm_auto(_nm_auto_nmpobj_cleanup)
|
2015-04-14 23:14:06 +02:00
|
|
|
|
|
|
|
|
typedef struct _NMPCache NMPCache;
|
|
|
|
|
|
|
|
|
|
typedef void (*NMPCachePreHook) (NMPCache *cache, const NMPObject *old, const NMPObject *new, NMPCacheOpsType ops_type, gpointer user_data);
|
|
|
|
|
typedef gboolean (*NMPObjectMatchFn) (const NMPObject *obj, gpointer user_data);
|
|
|
|
|
|
2017-08-05 09:57:30 +02:00
|
|
|
const NMDedupMultiEntry *nmp_cache_lookup_entry (const NMPCache *cache,
|
|
|
|
|
const NMPObject *obj);
|
|
|
|
|
const NMDedupMultiEntry *nmp_cache_lookup_entry_with_idx_type (const NMPCache *cache,
|
|
|
|
|
NMPCacheIdType cache_id_type,
|
|
|
|
|
const NMPObject *obj);
|
|
|
|
|
const NMDedupMultiEntry *nmp_cache_lookup_entry_link (const NMPCache *cache,
|
|
|
|
|
int ifindex);
|
|
|
|
|
const NMPObject *nmp_cache_lookup_obj (const NMPCache *cache,
|
|
|
|
|
const NMPObject *obj);
|
|
|
|
|
const NMPObject *nmp_cache_lookup_link (const NMPCache *cache,
|
|
|
|
|
int ifindex);
|
2015-04-14 23:14:06 +02:00
|
|
|
|
2017-06-29 14:46:32 +02:00
|
|
|
typedef struct _NMPLookup NMPLookup;
|
|
|
|
|
|
|
|
|
|
struct _NMPLookup {
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
NMPCacheIdType cache_id_type;
|
|
|
|
|
NMPObject selector_obj;
|
2017-06-29 14:46:32 +02:00
|
|
|
};
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
|
|
|
|
|
const NMDedupMultiHeadEntry *nmp_cache_lookup_all (const NMPCache *cache,
|
|
|
|
|
NMPCacheIdType cache_id_type,
|
|
|
|
|
const NMPObject *select_obj);
|
|
|
|
|
|
|
|
|
|
static inline const NMDedupMultiHeadEntry *
|
|
|
|
|
nmp_cache_lookup (const NMPCache *cache,
|
|
|
|
|
const NMPLookup *lookup)
|
|
|
|
|
{
|
|
|
|
|
return nmp_cache_lookup_all (cache, lookup->cache_id_type, &lookup->selector_obj);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const NMPLookup *nmp_lookup_init_obj_type (NMPLookup *lookup,
|
2017-07-04 11:44:27 +02:00
|
|
|
NMPObjectType obj_type);
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
const NMPLookup *nmp_lookup_init_link_by_ifname (NMPLookup *lookup,
|
|
|
|
|
const char *ifname);
|
2017-11-23 15:41:57 +01:00
|
|
|
const NMPLookup *nmp_lookup_init_object (NMPLookup *lookup,
|
|
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
int ifindex);
|
2017-08-11 10:15:25 +02:00
|
|
|
const NMPLookup *nmp_lookup_init_route_default (NMPLookup *lookup,
|
|
|
|
|
NMPObjectType obj_type);
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
const NMPLookup *nmp_lookup_init_route_by_weak_id (NMPLookup *lookup,
|
|
|
|
|
const NMPObject *obj);
|
|
|
|
|
const NMPLookup *nmp_lookup_init_ip4_route_by_weak_id (NMPLookup *lookup,
|
|
|
|
|
in_addr_t network,
|
|
|
|
|
guint plen,
|
|
|
|
|
guint32 metric,
|
|
|
|
|
guint8 tos);
|
|
|
|
|
const NMPLookup *nmp_lookup_init_ip6_route_by_weak_id (NMPLookup *lookup,
|
|
|
|
|
const struct in6_addr *network,
|
|
|
|
|
guint plen,
|
|
|
|
|
guint32 metric,
|
|
|
|
|
const struct in6_addr *src,
|
|
|
|
|
guint8 src_plen);
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
const NMPLookup *nmp_lookup_init_object_by_addr_family (NMPLookup *lookup,
|
|
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
int addr_family);
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
|
|
|
|
|
GArray *nmp_cache_lookup_to_array (const NMDedupMultiHeadEntry *head_entry,
|
2017-07-04 11:44:27 +02:00
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
gboolean visible_only);
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nmp_cache_iter_next (NMDedupMultiIter *iter, const NMPObject **out_obj)
|
|
|
|
|
{
|
|
|
|
|
gboolean has_next;
|
|
|
|
|
|
|
|
|
|
has_next = nm_dedup_multi_iter_next (iter);
|
2017-09-21 13:13:27 +02:00
|
|
|
nm_assert (!has_next || NMP_OBJECT_IS_VALID (iter->current->obj));
|
|
|
|
|
if (out_obj)
|
|
|
|
|
*out_obj = has_next ? iter->current->obj : NULL;
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
return has_next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nmp_cache_iter_next_link (NMDedupMultiIter *iter, const NMPlatformLink **out_obj)
|
|
|
|
|
{
|
|
|
|
|
gboolean has_next;
|
|
|
|
|
|
|
|
|
|
has_next = nm_dedup_multi_iter_next (iter);
|
2017-09-21 13:13:27 +02:00
|
|
|
nm_assert (!has_next || NMP_OBJECT_GET_TYPE (iter->current->obj) == NMP_OBJECT_TYPE_LINK);
|
|
|
|
|
if (out_obj)
|
|
|
|
|
*out_obj = has_next ? &(((const NMPObject *) iter->current->obj)->link) : NULL;
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
return has_next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define nmp_cache_iter_for_each(iter, head, obj) \
|
|
|
|
|
for (nm_dedup_multi_iter_init ((iter), \
|
|
|
|
|
(head)); \
|
|
|
|
|
nmp_cache_iter_next ((iter), (obj)); \
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
#define nmp_cache_iter_for_each_link(iter, head, obj) \
|
|
|
|
|
for (nm_dedup_multi_iter_init ((iter), \
|
|
|
|
|
(head)); \
|
|
|
|
|
nmp_cache_iter_next_link ((iter), (obj)); \
|
|
|
|
|
)
|
|
|
|
|
|
2015-04-14 23:14:06 +02:00
|
|
|
const NMPObject *nmp_cache_lookup_link_full (const NMPCache *cache,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const char *ifname,
|
|
|
|
|
gboolean visible_only,
|
|
|
|
|
NMLinkType link_type,
|
|
|
|
|
NMPObjectMatchFn match_fn,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
2017-07-04 12:49:47 +02:00
|
|
|
gboolean nmp_cache_link_connected_for_slave (int ifindex_master, const NMPObject *slave);
|
2015-04-14 23:14:06 +02:00
|
|
|
gboolean nmp_cache_link_connected_needs_toggle (const NMPCache *cache, const NMPObject *master, const NMPObject *potential_slave, const NMPObject *ignore_slave);
|
|
|
|
|
const NMPObject *nmp_cache_link_connected_needs_toggle_by_ifindex (const NMPCache *cache, int master_ifindex, const NMPObject *potential_slave, const NMPObject *ignore_slave);
|
|
|
|
|
|
|
|
|
|
gboolean nmp_cache_use_udev_get (const NMPCache *cache);
|
|
|
|
|
|
|
|
|
|
void ASSERT_nmp_cache_is_consistent (const NMPCache *cache);
|
|
|
|
|
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
NMPCacheOpsType nmp_cache_remove (NMPCache *cache,
|
|
|
|
|
const NMPObject *obj_needle,
|
|
|
|
|
gboolean equals_by_ptr,
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
gboolean only_dirty,
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
const NMPObject **out_obj_old);
|
|
|
|
|
NMPCacheOpsType nmp_cache_remove_netlink (NMPCache *cache,
|
|
|
|
|
const NMPObject *obj_needle,
|
|
|
|
|
const NMPObject **out_obj_old,
|
|
|
|
|
const NMPObject **out_obj_new);
|
|
|
|
|
NMPCacheOpsType nmp_cache_update_netlink (NMPCache *cache,
|
2017-08-05 15:14:44 +02:00
|
|
|
NMPObject *obj_hand_over,
|
|
|
|
|
gboolean is_dump,
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
const NMPObject **out_obj_old,
|
|
|
|
|
const NMPObject **out_obj_new);
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
NMPCacheOpsType nmp_cache_update_netlink_route (NMPCache *cache,
|
|
|
|
|
NMPObject *obj_hand_over,
|
|
|
|
|
gboolean is_dump,
|
|
|
|
|
guint16 nlmsgflags,
|
|
|
|
|
const NMPObject **out_obj_old,
|
|
|
|
|
const NMPObject **out_obj_new,
|
|
|
|
|
const NMPObject **out_obj_replace,
|
|
|
|
|
gboolean *out_resync_required);
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
NMPCacheOpsType nmp_cache_update_link_udev (NMPCache *cache,
|
|
|
|
|
int ifindex,
|
|
|
|
|
struct udev_device *udevice,
|
|
|
|
|
const NMPObject **out_obj_old,
|
|
|
|
|
const NMPObject **out_obj_new);
|
|
|
|
|
NMPCacheOpsType nmp_cache_update_link_master_connected (NMPCache *cache,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const NMPObject **out_obj_old,
|
|
|
|
|
const NMPObject **out_obj_new);
|
|
|
|
|
|
2019-02-21 09:17:36 +01:00
|
|
|
static inline const NMDedupMultiEntry *
|
|
|
|
|
nmp_cache_reresolve_main_entry (NMPCache *cache,
|
|
|
|
|
const NMDedupMultiEntry *entry,
|
|
|
|
|
const NMPLookup *lookup)
|
|
|
|
|
{
|
|
|
|
|
const NMDedupMultiEntry *main_entry;
|
|
|
|
|
|
|
|
|
|
nm_assert (cache);
|
|
|
|
|
nm_assert (entry);
|
|
|
|
|
nm_assert (lookup);
|
|
|
|
|
|
|
|
|
|
if (lookup->cache_id_type == NMP_CACHE_ID_TYPE_OBJECT_TYPE) {
|
|
|
|
|
nm_assert (entry == nmp_cache_lookup_entry (cache, entry->obj));
|
|
|
|
|
return entry;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* we only track the dirty flag for the OBJECT-TYPE index. That means,
|
|
|
|
|
* for other lookup types we need to check the dirty flag of the main-entry. */
|
|
|
|
|
main_entry = nmp_cache_lookup_entry (cache, entry->obj);
|
|
|
|
|
|
|
|
|
|
nm_assert (main_entry);
|
|
|
|
|
nm_assert (main_entry->obj == entry->obj);
|
|
|
|
|
|
|
|
|
|
return main_entry;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void nmp_cache_dirty_set_all_main (NMPCache *cache,
|
|
|
|
|
const NMPLookup *lookup);
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
|
|
|
|
|
NMPCache *nmp_cache_new (NMDedupMultiIndex *multi_idx, gboolean use_udev);
|
2015-04-14 23:14:06 +02:00
|
|
|
void nmp_cache_free (NMPCache *cache);
|
|
|
|
|
|
platform: use NMDedupMultiIndex for routes in NMPCache
Rework platform object cache to use NMDedupMultiIndex.
Already previously, NMPCache used NMMultiIndex and had thus
O(1) for most operations. What is new is:
- Contrary to NMMultiIndex, NMDedupMultiIndex preserves the order of
the cached items. That is crucial to handle routes properly as kernel
will replace the first matching route based on network/plen/metric
properties. See related bug rh#1337855.
Without tracking the order of routes as they are exposed
by kernel, we cannot properly maintain the route cache.
- All NMPObject instances are now treated immutable, refcounted
and get de-duplicated via NMDedupMultiIndex. This allows
to have a global NMDedupMultiIndex that can be shared with
NMIP4Config and NMRouteManager. It also allows to share the
objects themselves.
Immutable objects are so much nicer. We can get rid of the
update pre-hook callback, which was required previously because
we would mutate the object inplace. Now, we can just update
the cache, and compare obj_old and obj_new after the fact.
- NMMultiIndex was treated as an internal of NMPCache. On the other
hand, NMDedupMultiIndex exposes NMDedupMultiHeadEntry, which is
basically an object that allows to iterate over all related
objects. That means, we can now lookup objects in the cache
and give the NMDedupMultiHeadEntry instance to the caller,
which then can iterate the list on it's own -- without need
for copying anything.
Currently, at various places we still create copies of lookup
results. That can be improved later.
The ability to share NMPObject instances should enable us to
significantly improve performance and scale with large number
of routes.
Of course there is a memory overhead of having an index for each list
entry. Each NMPObject may also require an NMDedupMultiEntry,
NMDedupMultiHeadEntry, and NMDedupMultiBox item, which are tracked
in a GHashTable. Optimally, one NMDedupMultiHeadEntry is the head
for multiple objects, and NMDedupMultiBox is able to deduplicate several
NMPObjects, so that there is a net saving.
Also, each object type has several indexes of type NMPCacheIdType.
So, worst case an NMPlatformIP4Route in the platform cache is tracked
by 8 NMPCacheIdType indexes, for each we require a NMDedupMultiEntry,
plus the shared NMDedupMultiHeadEntry. The NMDedupMultiBox instance
is shared between the 8 indexes (and possibly other).
2017-06-21 10:53:34 +02:00
|
|
|
static inline void
|
|
|
|
|
ASSERT_nmp_cache_ops (const NMPCache *cache,
|
|
|
|
|
NMPCacheOpsType ops_type,
|
|
|
|
|
const NMPObject *obj_old,
|
|
|
|
|
const NMPObject *obj_new)
|
|
|
|
|
{
|
|
|
|
|
#if NM_MORE_ASSERTS
|
|
|
|
|
nm_assert (cache);
|
|
|
|
|
nm_assert (obj_old || obj_new);
|
|
|
|
|
nm_assert (!obj_old || ( NMP_OBJECT_IS_VALID (obj_old)
|
|
|
|
|
&& !NMP_OBJECT_IS_STACKINIT (obj_old)
|
|
|
|
|
&& nmp_object_is_alive (obj_old)));
|
|
|
|
|
nm_assert (!obj_new || ( NMP_OBJECT_IS_VALID (obj_new)
|
|
|
|
|
&& !NMP_OBJECT_IS_STACKINIT (obj_new)
|
|
|
|
|
&& nmp_object_is_alive (obj_new)));
|
|
|
|
|
|
|
|
|
|
switch (ops_type) {
|
|
|
|
|
case NMP_CACHE_OPS_UNCHANGED:
|
|
|
|
|
nm_assert (obj_old == obj_new);
|
|
|
|
|
break;
|
|
|
|
|
case NMP_CACHE_OPS_ADDED:
|
|
|
|
|
nm_assert (!obj_old && obj_new);
|
|
|
|
|
break;
|
|
|
|
|
case NMP_CACHE_OPS_UPDATED:
|
|
|
|
|
nm_assert (obj_old && obj_new && obj_old != obj_new);
|
|
|
|
|
break;
|
|
|
|
|
case NMP_CACHE_OPS_REMOVED:
|
|
|
|
|
nm_assert (obj_old && !obj_new);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
nm_assert_not_reached ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nm_assert (obj_new == NULL || obj_old == NULL || nmp_object_id_equal (obj_new, obj_old));
|
|
|
|
|
nm_assert (!obj_old || !obj_new || NMP_OBJECT_GET_CLASS (obj_old) == NMP_OBJECT_GET_CLASS (obj_new));
|
|
|
|
|
|
|
|
|
|
nm_assert (obj_new == nmp_cache_lookup_obj (cache, obj_new ?: obj_old));
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
const NMDedupMultiHeadEntry *nm_platform_lookup_all (NMPlatform *platform,
|
|
|
|
|
NMPCacheIdType cache_id_type,
|
2017-08-14 14:16:20 +02:00
|
|
|
const NMPObject *obj);
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
|
|
|
|
|
const NMDedupMultiEntry *nm_platform_lookup_entry (NMPlatform *platform,
|
|
|
|
|
NMPCacheIdType cache_id_type,
|
2017-08-14 14:16:20 +02:00
|
|
|
const NMPObject *obj);
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
|
2018-02-09 13:19:49 +01:00
|
|
|
static inline const NMPObject *
|
|
|
|
|
nm_platform_lookup_obj (NMPlatform *platform,
|
|
|
|
|
NMPCacheIdType cache_id_type,
|
|
|
|
|
const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
return nm_dedup_multi_entry_get_obj (nm_platform_lookup_entry (platform,
|
|
|
|
|
cache_id_type,
|
|
|
|
|
obj));
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-29 14:46:32 +02:00
|
|
|
static inline const NMDedupMultiHeadEntry *
|
|
|
|
|
nm_platform_lookup_obj_type (NMPlatform *platform,
|
2017-07-04 11:44:27 +02:00
|
|
|
NMPObjectType obj_type)
|
2017-06-29 14:46:32 +02:00
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
2017-07-04 11:44:27 +02:00
|
|
|
nmp_lookup_init_obj_type (&lookup, obj_type);
|
2017-06-29 14:46:32 +02:00
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const NMDedupMultiHeadEntry *
|
|
|
|
|
nm_platform_lookup_link_by_ifname (NMPlatform *platform,
|
|
|
|
|
const char *ifname)
|
|
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
|
|
|
|
nmp_lookup_init_link_by_ifname (&lookup, ifname);
|
|
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const NMDedupMultiHeadEntry *
|
2017-11-23 15:41:57 +01:00
|
|
|
nm_platform_lookup_object (NMPlatform *platform,
|
|
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
int ifindex)
|
2017-06-29 14:46:32 +02:00
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
2017-11-23 15:41:57 +01:00
|
|
|
nmp_lookup_init_object (&lookup, obj_type, ifindex);
|
2017-06-29 14:46:32 +02:00
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 10:15:25 +02:00
|
|
|
static inline GPtrArray *
|
2017-11-23 15:41:57 +01:00
|
|
|
nm_platform_lookup_object_clone (NMPlatform *platform,
|
|
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPObjectPredicateFunc predicate,
|
|
|
|
|
gpointer user_data)
|
2017-08-11 10:15:25 +02:00
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
2017-11-23 15:41:57 +01:00
|
|
|
nmp_lookup_init_object (&lookup, obj_type, ifindex);
|
2017-08-11 10:15:25 +02:00
|
|
|
return nm_platform_lookup_clone (platform, &lookup, predicate, user_data);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-29 14:46:32 +02:00
|
|
|
static inline const NMDedupMultiHeadEntry *
|
2017-08-11 10:15:25 +02:00
|
|
|
nm_platform_lookup_route_default (NMPlatform *platform,
|
|
|
|
|
NMPObjectType obj_type)
|
2017-06-29 14:46:32 +02:00
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
2017-08-11 10:15:25 +02:00
|
|
|
nmp_lookup_init_route_default (&lookup, obj_type);
|
2017-06-29 14:46:32 +02:00
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-29 15:19:35 +02:00
|
|
|
static inline GPtrArray *
|
2017-08-11 10:15:25 +02:00
|
|
|
nm_platform_lookup_route_default_clone (NMPlatform *platform,
|
2017-06-29 15:19:35 +02:00
|
|
|
NMPObjectType obj_type,
|
2017-08-14 14:52:55 +02:00
|
|
|
NMPObjectPredicateFunc predicate,
|
2017-06-29 15:19:35 +02:00
|
|
|
gpointer user_data)
|
|
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
2017-08-11 10:15:25 +02:00
|
|
|
nmp_lookup_init_route_default (&lookup, obj_type);
|
2017-06-29 15:19:35 +02:00
|
|
|
return nm_platform_lookup_clone (platform, &lookup, predicate, user_data);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-29 14:46:32 +02:00
|
|
|
static inline const NMDedupMultiHeadEntry *
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
nm_platform_lookup_ip4_route_by_weak_id (NMPlatform *platform,
|
|
|
|
|
in_addr_t network,
|
|
|
|
|
guint plen,
|
|
|
|
|
guint32 metric,
|
|
|
|
|
guint8 tos)
|
|
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
|
|
|
|
nmp_lookup_init_ip4_route_by_weak_id (&lookup, network, plen, metric, tos);
|
|
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const NMDedupMultiHeadEntry *
|
|
|
|
|
nm_platform_lookup_ip6_route_by_weak_id (NMPlatform *platform,
|
|
|
|
|
const struct in6_addr *network,
|
|
|
|
|
guint plen,
|
|
|
|
|
guint32 metric,
|
|
|
|
|
const struct in6_addr *src,
|
|
|
|
|
guint8 src_plen)
|
2017-06-29 14:46:32 +02:00
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
platform: fix cache to use kernel's notion for equality of routes
Until now, NetworkManager's platform cache for routes used the quadruple
network/plen,metric,ifindex for equaliy. That is not kernel's
understanding of how routes behave. For example, with `ip route append`
you can add two IPv4 routes that only differ by their gateway. To
the previous form of platform cache, these two routes would wrongly
look identical, as the cache could not contain both routes. This also
easily leads to cache-inconsistencies.
Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
compare operator to match kernel's.
Well, not entirely. Kernel understands more properties for routes then
NetworkManager. Some of these properties may also be part of the ID according
to kernel. To NetworkManager such routes would still look identical as
they only differ in a property that is not understood. This can still
cause cache-inconsistencies. The only fix here is to add support for
all these properties in NetworkManager as well. However, it's less serious,
because with this commit we support several of the more important properties.
See also the related bug rh#1337855 for kernel.
Another difficulty is that `ip route replace` and `ip route change`
changes an existing route. The replaced route has the same
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
# ip -d -4 route show dev v
# ip monitor route &
# ip route add 192.168.5.0/24 dev v
192.168.5.0/24 dev v scope link
# ip route change 192.168.5.0/24 dev v scope 10
192.168.5.0/24 dev v scope 10
# ip -d -4 route show dev v
unicast 192.168.5.0/24 proto boot scope 10
Note that we only got one RTM_NEWROUTE message, although from NMPCache's
point of view, a new route (with a particular ID) was added and another
route (with a different ID) was deleted. The cumbersome workaround is,
to keep an ordered list of the routes, and figure out which route was
replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
work fine. However, as we only rely on events, we might wrongly
introduce a cache-inconsistancy as well. See the related bug rh#1337860.
Also drop nm_platform_ip4_route_get() and the like. The ID of routes
is complex, so it makes little sense to look up a route directly.
2017-08-02 07:55:05 +02:00
|
|
|
nmp_lookup_init_ip6_route_by_weak_id (&lookup, network, plen, metric, src, src_plen);
|
2017-06-29 14:46:32 +02:00
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-11 17:59:45 +02:00
|
|
|
static inline const NMDedupMultiHeadEntry *
|
|
|
|
|
nm_platform_lookup_object_by_addr_family (NMPlatform *platform,
|
|
|
|
|
NMPObjectType obj_type,
|
|
|
|
|
int addr_family)
|
|
|
|
|
{
|
|
|
|
|
NMPLookup lookup;
|
|
|
|
|
|
|
|
|
|
nmp_lookup_init_object_by_addr_family (&lookup, obj_type, addr_family);
|
|
|
|
|
return nm_platform_lookup (platform, &lookup);
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-21 12:14:17 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
|
nmp_object_link_get_ifname (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
if (!obj)
|
|
|
|
|
return NULL;
|
|
|
|
|
return NMP_OBJECT_CAST_LINK (obj)->name;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-21 18:18:18 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
nmp_object_ip_route_is_best_defaut_route (const NMPObject *obj)
|
|
|
|
|
{
|
|
|
|
|
const NMPlatformIPRoute *r = NMP_OBJECT_CAST_IP_ROUTE (obj);
|
|
|
|
|
|
|
|
|
|
/* return whether @obj is considered a default-route.
|
|
|
|
|
*
|
|
|
|
|
* NMIP4Config/NMIP6Config tracks the (best) default-route explicitly, because
|
|
|
|
|
* at various places we act differently depending on whether there is a default-route
|
|
|
|
|
* configured.
|
|
|
|
|
*
|
|
|
|
|
* Note that this only considers the main routing table. */
|
|
|
|
|
return r
|
|
|
|
|
&& NM_PLATFORM_IP_ROUTE_IS_DEFAULT (r)
|
|
|
|
|
&& nm_platform_route_table_is_main (r->table_coerced)
|
|
|
|
|
&& r->type_coerced == nm_platform_route_type_coerce (1 /* RTN_UNICAST */);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 22:34:01 +02:00
|
|
|
#endif /* __NMP_OBJECT_H__ */
|