fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-30 01:30:12 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/shared/nm-platform/nm-platform-utils.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1808 lines
66 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
all: manually drop code comments with file description
2019-09-25 13:13:40 +02:00
/*
platform: add nm-platform-utils.[ch] files There is no general purpose file for platform utilities. We only have nm-platform.h, which contains (mostly) functions that operate on a NMPlatform instance (and that can be mocked using NMFakePlatform). Add a new file for independent utility functions. nm-platform-utils.c should not call into functions having a NMPlatform instance, to have them independent from platform caching and the platform singleton.
2015-04-14 22:34:01 +02:00
* Copyright (C) 2015 Red Hat, Inc.
*/
all: add "nm-glib-aux/nm-default-glib-i18n-lib.h" as replacement for "nm-default.h"
2021-02-04 08:48:06 +01:00
#include "nm-glib-aux/nm-default-glib-i18n-lib.h"
core: split "nm-core-utils.h" out of "NetworkManagerUtils.h" "NetworkManagerUtils.h" contains a bunch of helper tools for core daemon ("src/"). Unfortunately, it has dependencies to other parts of core, such as "nm-device.h" and "nm-platform.h". Split out a part of tools that are independent so that they can be used without dragging in other dependencies. "nm-core-utils.h" should only use libnm-core, "nm-logging.h" and shared. "NetworkManagerUtils.h" should provide all "nm-core-utils.h" and possibly other utilities that have larger dependencies.
2016-03-01 09:56:51 +01:00
platform: add nm-platform-utils.[ch] files There is no general purpose file for platform utilities. We only have nm-platform.h, which contains (mostly) functions that operate on a NMPlatform instance (and that can be mocked using NMFakePlatform). Add a new file for independent utility functions. nm-platform-utils.c should not call into functions having a NMPlatform instance, to have them independent from platform caching and the platform singleton.
2015-04-14 22:34:01 +02:00
#include "nm-platform-utils.h"
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/ethtool.h>
#include <linux/sockios.h>
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
#include <linux/mii.h>
build: avoid header conflict for <linux/if.h> and <net/if.h> with "nm-platform.h" In the past, the headers "linux/if.h" and "net/if.h" were incompatible. That means, we can either include one or the other, but not both. This is fixed in the meantime, however the issue still exists when building against older kernel/glibc. That means, including one of these headers from a header file is problematic. In particular if it's a header like "nm-platform.h", which itself is dragged in by many other headers. Avoid that by not including these headers from "platform.h", but instead from the source files where needed (or possibly from less popular header files). Currently there is no problem. However, this allows an unknowing user to include <net/if.h> at the same time with "nm-platform.h", which is easy to get wrong.
2018-11-12 15:23:36 +01:00
#include <linux/if.h>
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
#include <linux/version.h>
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
#include <linux/rtnetlink.h>
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
#include <fcntl.h>
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
#include <libudev.h>
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
libnm,shared: move nm-ethtool helper to "libnm-base" We want to use this by "shared/nm-platform", which should have no dependency on "libnm-core". Move "libnm-core/nm-ethtool-utils.h" to "libnm/nm-ethtool-utils.h" so that it is only used by libnm. This file contains the defines for the option names. Also, symlink "libnm/nm-ethtool-utils.h" as "shared/nm-base/nm-ethtool-utils-base.h". We want to use the same defines also internally. Since they are both public API (must be in libnm) and should be in "shared/nm-base", this is the way.
2021-01-09 12:00:33 +01:00
#include "nm-base/nm-ethtool-base.h"
platform: move "nm-platform-utils.[hc]" to "shared/nm-platform" library By now it has no further dependencies on libnm-core or NetworkManager core. Make it part of "shared/nm-platform" library.
2021-01-10 09:55:06 +01:00
#include "nm-log-core/nm-logging.h"
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform: move types from "nm-platform-utils.h" to nmp-base.h" Thereby, also no longer include "nm-platform.h" and "nm-setting-wired.h" in "nm-platform-utils.h".
2021-01-08 18:39:27 +01:00
/*****************************************************************************/
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
#define ONOFF(bool_val) ((bool_val) ? "on" : "off")
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/******************************************************************************
platform: add wrappers for if_nametoindex() and if_indextoname()
2016-12-26 11:54:30 +01:00
* utils
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
*****************************************************************************/
platform: add wrappers for if_nametoindex() and if_indextoname()
2016-12-26 11:54:30 +01:00
all: use "unsigned" instead of "unsigned int"
2017-03-14 11:15:05 +01:00
extern char *if_indextoname(unsigned __ifindex, char *__ifname);
unsigned if_nametoindex(const char *__ifname);
platform: add wrappers for if_nametoindex() and if_indextoname()
2016-12-26 11:54:30 +01:00
const char *
nmp_utils_if_indextoname(int ifindex, char *out_ifname /*IFNAMSIZ*/)
{
g_return_val_if_fail(ifindex > 0, NULL);
g_return_val_if_fail(out_ifname, NULL);
return if_indextoname(ifindex, out_ifname);
}
int
nmp_utils_if_nametoindex(const char *ifname)
{
g_return_val_if_fail(ifname, 0);
return if_nametoindex(ifname);
}
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
/*****************************************************************************/
platform: move nm_platform_link_duplex_type_to_string() to "nm-platform-utils.c" There should be a clear hierarchie of dependency. That is, "nm-platform.h" may use "nm-platform-utils.h", but not the other way around. Move nm_platform_link_duplex_type_to_string().
2021-01-08 20:24:36 +01:00
NM_UTILS_LOOKUP_STR_DEFINE(nm_platform_link_duplex_type_to_string,
NMPlatformLinkDuplexType,
NM_UTILS_LOOKUP_DEFAULT_WARN(NULL),
NM_UTILS_LOOKUP_STR_ITEM(NM_PLATFORM_LINK_DUPLEX_UNKNOWN, "unknown"),
NM_UTILS_LOOKUP_STR_ITEM(NM_PLATFORM_LINK_DUPLEX_FULL, "full"),
NM_UTILS_LOOKUP_STR_ITEM(NM_PLATFORM_LINK_DUPLEX_HALF, "half"), );
/*****************************************************************************/
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
typedef struct {
int fd;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
const int ifindex;
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
char ifname[IFNAMSIZ];
} SocketHandle;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
#define SOCKET_HANDLE_INIT(_ifindex) \
{ \
.fd = -1, .ifindex = (_ifindex), \
}
static void
_nm_auto_socket_handle(SocketHandle *shandle)
{
if (shandle->fd >= 0)
nm_close(shandle->fd);
}
#define nm_auto_socket_handle nm_auto(_nm_auto_socket_handle)
/*****************************************************************************/
typedef enum {
IOCTL_CALL_DATA_TYPE_NONE,
IOCTL_CALL_DATA_TYPE_IFRDATA,
IOCTL_CALL_DATA_TYPE_IFRU,
} IoctlCallDataType;
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
static int
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
_ioctl_call(const char * log_ioctl_type,
const char * log_subtype,
unsigned long int ioctl_request,
int ifindex,
int * inout_fd,
char * inout_ifname,
IoctlCallDataType edata_type,
gpointer edata,
gsize edata_size,
struct ifreq * out_ifreq)
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_close int fd_close = -1;
int fd;
int r;
gpointer edata_backup = NULL;
gs_free gpointer edata_backup_free = NULL;
guint try_count;
char known_ifnames[2][IFNAMSIZ];
const char * failure_reason = NULL;
struct ifreq ifr;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_assert(ifindex > 0);
nm_assert(NM_IN_SET(edata_type,
IOCTL_CALL_DATA_TYPE_NONE,
IOCTL_CALL_DATA_TYPE_IFRDATA,
IOCTL_CALL_DATA_TYPE_IFRU));
nm_assert(edata_type != IOCTL_CALL_DATA_TYPE_NONE || edata_size == 0);
nm_assert(edata_type != IOCTL_CALL_DATA_TYPE_IFRDATA || edata_size > 0);
nm_assert(edata_type != IOCTL_CALL_DATA_TYPE_IFRU
|| (edata_size > 0 && edata_size <= sizeof(ifr.ifr_ifru)));
nm_assert(edata_size == 0 || edata);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
/* open a file descriptor (or use the one provided). */
if (inout_fd && *inout_fd >= 0)
fd = *inout_fd;
else {
fd = socket(PF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0);
if (fd < 0) {
r = -NM_ERRNO_NATIVE(errno);
failure_reason = "failed creating socket or ioctl";
goto out;
}
if (inout_fd)
*inout_fd = fd;
else
fd_close = fd;
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
/* resolve the ifindex to name (or use the one provided). */
if (inout_ifname && inout_ifname[0])
nm_utils_ifname_cpy(known_ifnames[0], inout_ifname);
else {
if (!nmp_utils_if_indextoname(ifindex, known_ifnames[0])) {
failure_reason = "cannot resolve ifindex";
r = -ENODEV;
goto out;
}
if (inout_ifname)
nm_utils_ifname_cpy(inout_ifname, known_ifnames[0]);
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
/* we might need to retry the request. Backup edata so that we can
* restore it on retry. */
if (edata_size > 0)
edata_backup = nm_memdup_maybe_a(500, edata, edata_size, &edata_backup_free);
try_count = 0;
again:
{
const char *ifname = known_ifnames[try_count % 2];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_assert(ifindex > 0);
all: use nm_utils_ifname_valid_kernel() instead of nm_utils_is_valid_iface_name() nm_utils_is_valid_iface_name() is a public API of libnm-core, let's use our internal API. $ sed -i 's/\<nm_utils_is_valid_iface_name\>/nm_utils_ifname_valid_kernel/g' $(git grep -l nm_utils_is_valid_iface_name)
2020-02-12 18:01:13 +01:00
nm_assert(ifname && nm_utils_ifname_valid_kernel(ifname, NULL));
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_assert(fd >= 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: use memset() to initialize ifr struct in _ioctl_call() "struct ifreq" contains a union field, and initalizing the struct is not guaranteed to fill all bytes with zero (it only sets the first union member to zero). Since we later return the entire struct, ensure that it's initialized to all zero by using memset().
2019-05-15 21:00:52 +02:00
memset(&ifr, 0, sizeof(ifr));
platform: avoid valgrind warning about uninitialised memory in _ioctl_call() ==6207== Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s) ==6207== at 0x514603B: ioctl (syscall-template.S:78) ==6207== by 0x19FC2F: _ioctl_call (nm-platform-utils.c:183) ==6207== by 0x1A026B: _ethtool_call_handle (nm-platform-utils.c:319) ==6207== by 0x1A031F: ethtool_get_stringset (nm-platform-utils.c:378) ==6207== by 0x1A03BC: ethtool_get_stringset_index (nm-platform-utils.c:414) ==6207== by 0x1A181E: nmp_utils_ethtool_supports_vlans (nm-platform-utils.c:912) ==6207== by 0x1756D7: link_supports_vlans (nm-linux-platform.c:6508) ==6207== by 0x1A81D8: nm_platform_link_supports_vlans (nm-platform.c:1536) ==6207== by 0x14B96B: test_internal (test-link.c:602) ==6207== by 0x4F5C18D: test_case_run (gtestutils.c:2597) ==6207== by 0x4F5C18D: g_test_run_suite_internal (gtestutils.c:2685) ==6207== by 0x4F5BF33: g_test_run_suite_internal (gtestutils.c:2697) ==6207== by 0x4F5C679: g_test_run_suite (gtestutils.c:2772) ==6207== by 0x4F5C694: g_test_run (gtestutils.c:2007) ==6207== by 0x166B4D: main (test-common.c:2092) ==6207== Address 0x1ffeffeecf is on thread 1's stack ==6207== in frame #1, created by _ioctl_call (nm-platform-utils.c:110) ==6207== "ifname" is the stack-allocated array "known_ifnames" of suitable IFNAMSIZ bytes. But it may not be fully initialized, so using memcpy() to copy the string leads to unintialized warning. We really should only copy the valid bytes, either with strcpy() or our nm_utils_ifname_cpy() wrapper. Fixes: 856322562eff ('platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii')
2019-05-16 10:11:39 +02:00
nm_utils_ifname_cpy(ifr.ifr_name, ifname);
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (edata_type == IOCTL_CALL_DATA_TYPE_IFRDATA)
ifr.ifr_data = edata;
else if (edata_type == IOCTL_CALL_DATA_TYPE_IFRU)
memcpy(&ifr.ifr_ifru, edata, NM_MIN(edata_size, sizeof(ifr.ifr_ifru)));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (ioctl(fd, ioctl_request, &ifr) < 0) {
r = -NM_ERRNO_NATIVE(errno);
nm_log_trace(LOGD_PLATFORM,
"%s[%d]: %s, %s: failed: %s",
log_ioctl_type,
ifindex,
log_subtype,
ifname,
nm_strerror_native(-r));
} else {
r = 0;
nm_log_trace(LOGD_PLATFORM,
"%s[%d]: %s, %s: success",
log_ioctl_type,
ifindex,
log_subtype,
ifname);
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
try_count++;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
/* resolve the name again to see whether the ifindex still has the same name. */
if (!nmp_utils_if_indextoname(ifindex, known_ifnames[try_count % 2])) {
/* we could not find the ifindex again. Probably the device just got
* removed.
*
* In both cases we return the error code we got from ioctl above.
* Either it failed because the device was gone already or it still
* managed to complete the call. In both cases, the error code is good. */
failure_reason =
"cannot resolve ifindex after ioctl call. Probably the device was just removed";
goto out;
}
/* check whether the ifname changed in the meantime. If yes, would render the result
* invalid. Note that this cannot detect every race regarding renames, for example:
*
* - if_indextoname(#10) gives eth0
* - rename(#10) => eth0_tmp
* - rename(#11) => eth0
* - ioctl(eth0) (wrongly fetching #11, formerly eth1)
* - rename(#11) => eth_something
* - rename(#10) => eth0
* - if_indextoname(#10) gives eth0
*/
if (!nm_streq(known_ifnames[0], known_ifnames[1])) {
gboolean retry;
/* we detected a possible(!) rename.
*
* For getters it's straight forward to just retry the call.
*
* For setters we also always retry. If our previous call operated on the right device,
* calling it again should have no bad effect (just setting the same thing more than once).
*
* The only potential bad thing is if there was a race involving swapping names, and we just
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* set the ioctl option on the wrong device. But then the bad thing already happenned and
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
* we cannot detect it (nor do anything about it). At least, we can retry and set the
* option on the right interface. */
retry = (try_count < 5);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_log_trace(LOGD_PLATFORM,
"%s[%d]: %s: rename detected from \"%s\" to \"%s\". %s",
log_ioctl_type,
ifindex,
log_subtype,
known_ifnames[(try_count - 1) % 2],
known_ifnames[try_count % 2],
retry ? "Retry" : "No retry");
if (inout_ifname)
nm_utils_ifname_cpy(inout_ifname, known_ifnames[try_count % 2]);
if (retry) {
if (edata_size > 0)
memcpy(edata, edata_backup, edata_size);
goto again;
}
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
}
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
out:
if (failure_reason) {
nm_log_trace(LOGD_PLATFORM,
"%s[%d]: %s: %s: %s",
log_ioctl_type,
ifindex,
log_subtype,
failure_reason,
r < 0 ? nm_strerror_native(-r) : "assume success");
}
if (r >= 0)
NM_SET_OUT(out_ifreq, ifr);
return r;
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
}
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/******************************************************************************
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
* ethtool
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
*****************************************************************************/
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
shared: drop _STATIC variant of macros that define functions Several macros are used to define function. They had a "_STATIC" variant, to define the function as static. I think those macros should not try to abstract entirely what they do. They should not accept the function scope as argument (or have two variants per scope). This also because it might make sense to add additional __attribute__(()) to the function. That only works, if the macro does not pretend to *not* define a plain function. Instead, embrace what the function does and let the users place the function scope as they see fit. This also follows what is already done with static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
2020-02-13 14:55:26 +01:00
static NM_UTILS_ENUM2STR_DEFINE(_ethtool_cmd_to_string,
guint32,
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
NM_UTILS_ENUM2STR(ETHTOOL_GCOALESCE, "ETHTOOL_GCOALESCE"),
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
NM_UTILS_ENUM2STR(ETHTOOL_GDRVINFO, "ETHTOOL_GDRVINFO"),
NM_UTILS_ENUM2STR(ETHTOOL_GFEATURES, "ETHTOOL_GFEATURES"),
NM_UTILS_ENUM2STR(ETHTOOL_GLINK, "ETHTOOL_GLINK"),
NM_UTILS_ENUM2STR(ETHTOOL_GPERMADDR, "ETHTOOL_GPERMADDR"),
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
NM_UTILS_ENUM2STR(ETHTOOL_GRINGPARAM, "ETHTOOL_GRINGPARAM"),
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
NM_UTILS_ENUM2STR(ETHTOOL_GSET, "ETHTOOL_GSET"),
NM_UTILS_ENUM2STR(ETHTOOL_GSSET_INFO, "ETHTOOL_GSSET_INFO"),
NM_UTILS_ENUM2STR(ETHTOOL_GSTATS, "ETHTOOL_GSTATS"),
NM_UTILS_ENUM2STR(ETHTOOL_GSTRINGS, "ETHTOOL_GSTRINGS"),
NM_UTILS_ENUM2STR(ETHTOOL_GWOL, "ETHTOOL_GWOL"),
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
NM_UTILS_ENUM2STR(ETHTOOL_SCOALESCE, "ETHTOOL_SCOALESCE"),
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
NM_UTILS_ENUM2STR(ETHTOOL_SFEATURES, "ETHTOOL_SFEATURES"),
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
NM_UTILS_ENUM2STR(ETHTOOL_SRINGPARAM, "ETHTOOL_SRINGPARAM"),
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
NM_UTILS_ENUM2STR(ETHTOOL_SSET, "ETHTOOL_SSET"),
NM_UTILS_ENUM2STR(ETHTOOL_SWOL, "ETHTOOL_SWOL"), );
static const char *
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
_ethtool_edata_to_string(gpointer edata, gsize edata_size, char *sbuf, gsize sbuf_len)
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_assert(edata);
nm_assert(edata_size >= sizeof(guint32));
nm_assert((((intptr_t) edata) % _nm_alignof(guint32)) == 0);
return _ethtool_cmd_to_string(*((guint32 *) edata), sbuf, sbuf_len);
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
}
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
/*****************************************************************************/
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 27)
#define ethtool_cmd_speed(pedata) ((pedata)->speed)
#define ethtool_cmd_speed_set(pedata, speed) \
G_STMT_START \
{ \
(pedata)->speed = (guint16)(speed); \
} \
G_STMT_END
#endif
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
static int
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
_ethtool_call_handle(SocketHandle *shandle, gpointer edata, gsize edata_size)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
char sbuf[50];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
return _ioctl_call("ethtool",
_ethtool_edata_to_string(edata, edata_size, sbuf, sizeof(sbuf)),
SIOCETHTOOL,
shandle->ifindex,
&shandle->fd,
shandle->ifname,
IOCTL_CALL_DATA_TYPE_IFRDATA,
edata,
edata_size,
NULL);
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
}
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
static int
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
_ethtool_call_once(int ifindex, gpointer edata, gsize edata_size)
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
{
char sbuf[50];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
return _ioctl_call("ethtool",
_ethtool_edata_to_string(edata, edata_size, sbuf, sizeof(sbuf)),
SIOCETHTOOL,
ifindex,
NULL,
NULL,
IOCTL_CALL_DATA_TYPE_IFRDATA,
edata,
edata_size,
NULL);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
}
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/*****************************************************************************/
static struct ethtool_gstrings *
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
ethtool_get_stringset(SocketHandle *shandle, int stringset_id)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
Revert "platform: fix GCC warning about zero-lenght array (1)" I think this solution is not right, because "char buf" is not guaranteed to have the correct alignment. Revert, and solve it differently. This reverts commit 6345a661535bd4aaf62b2ba4bee129762abb2954.
2020-02-10 10:51:49 +01:00
struct {
struct ethtool_sset_info info;
guint32 sentinel;
} sset_info = {
.info.cmd = ETHTOOL_GSSET_INFO,
.info.reserved = 0,
.info.sset_mask = (1ULL << stringset_id),
};
platform: fix GCC warning about zero-length array in ethtool_get_stringset() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’: src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds] 355 | len = sset_info.info.data[0]; | ~~~~~~~~~~~~~~~~~~~^~~ In file included from src/platform/nm-platform-utils.c:12: /usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’ 647 | __u32 data[0]; | ^~~~ Fix this warning.
2020-02-10 10:55:12 +01:00
const guint32 * pdata;
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
gs_free struct ethtool_gstrings *gstrings = NULL;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
gsize gstrings_len;
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
guint32 i, len;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
Revert "platform: fix GCC warning about zero-lenght array (1)" I think this solution is not right, because "char buf" is not guaranteed to have the correct alignment. Revert, and solve it differently. This reverts commit 6345a661535bd4aaf62b2ba4bee129762abb2954.
2020-02-10 10:51:49 +01:00
if (_ethtool_call_handle(shandle, &sset_info, sizeof(sset_info)) < 0)
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
return NULL;
Revert "platform: fix GCC warning about zero-lenght array (1)" I think this solution is not right, because "char buf" is not guaranteed to have the correct alignment. Revert, and solve it differently. This reverts commit 6345a661535bd4aaf62b2ba4bee129762abb2954.
2020-02-10 10:51:49 +01:00
if (!sset_info.info.sset_mask)
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: fix GCC warning about zero-length array in ethtool_get_stringset() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’: src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds] 355 | len = sset_info.info.data[0]; | ~~~~~~~~~~~~~~~~~~~^~~ In file included from src/platform/nm-platform-utils.c:12: /usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’ 647 | __u32 data[0]; | ^~~~ Fix this warning.
2020-02-10 10:55:12 +01:00
pdata = (guint32 *) sset_info.info.data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: fix GCC warning about zero-length array in ethtool_get_stringset() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’: src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds] 355 | len = sset_info.info.data[0]; | ~~~~~~~~~~~~~~~~~~~^~~ In file included from src/platform/nm-platform-utils.c:12: /usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’ 647 | __u32 data[0]; | ^~~~ Fix this warning.
2020-02-10 10:55:12 +01:00
len = *pdata;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
gstrings_len = sizeof(*gstrings) + (len * ETH_GSTRING_LEN);
gstrings = g_malloc0(gstrings_len);
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
gstrings->cmd = ETHTOOL_GSTRINGS;
gstrings->string_set = stringset_id;
gstrings->len = len;
if (gstrings->len > 0) {
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_handle(shandle, gstrings, gstrings_len) < 0)
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
return NULL;
for (i = 0; i < gstrings->len; i++) {
/* ensure NUL terminated */
gstrings->data[i * ETH_GSTRING_LEN + (ETH_GSTRING_LEN - 1)] = '\0';
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
return g_steal_pointer(&gstrings);
}
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
static int
ethtool_gstrings_find(const struct ethtool_gstrings *gstrings, const char *needle)
{
guint32 i;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/* ethtool_get_stringset() always ensures NUL terminated strings at ETH_GSTRING_LEN.
* that means, we cannot possibly request longer names. */
nm_assert(needle && strlen(needle) < ETH_GSTRING_LEN);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
for (i = 0; i < gstrings->len; i++) {
if (nm_streq((char *) &gstrings->data[i * ETH_GSTRING_LEN], needle))
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return i;
}
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
return -1;
}
static int
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
ethtool_get_stringset_index(SocketHandle *shandle, int stringset_id, const char *needle)
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
{
gs_free struct ethtool_gstrings *gstrings = NULL;
/* ethtool_get_stringset() always ensures NUL terminated strings at ETH_GSTRING_LEN.
* that means, we cannot possibly request longer names. */
nm_assert(needle && strlen(needle) < ETH_GSTRING_LEN);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
gstrings = ethtool_get_stringset(shandle, stringset_id);
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
if (gstrings)
return ethtool_gstrings_find(gstrings, needle);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return -1;
}
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/*****************************************************************************/
static const NMEthtoolFeatureInfo _ethtool_feature_infos[_NM_ETHTOOL_ID_FEATURE_NUM] = {
#define ETHT_FEAT(eid, ...) \
{ \
.ethtool_id = eid, .n_kernel_names = NM_NARG(__VA_ARGS__), \
.kernel_names = ((const char *const[]){__VA_ARGS__}), \
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/* the order does only matter for one thing: if it happens that more than one NMEthtoolID
* reference the same kernel-name, then the one that is mentioned *later* will win in
* case these NMEthtoolIDs are set. That mostly only makes sense for ethtool-ids which
* refer to multiple features ("feature-tso"), while also having more specific ids
* ("feature-tx-tcp-segmentation"). */
/* names from ethtool utility, which are aliases for multiple features. */
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_SG, "tx-scatter-gather", "tx-scatter-gather-fraglist"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TSO,
"tx-tcp-segmentation",
"tx-tcp-ecn-segmentation",
"tx-tcp-mangleid-segmentation",
"tx-tcp6-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX,
"tx-checksum-ipv4",
"tx-checksum-ip-generic",
"tx-checksum-ipv6",
"tx-checksum-fcoe-crc",
"tx-checksum-sctp"),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/* names from ethtool utility, which are aliases for one feature. */
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_GRO, "rx-gro"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_GSO, "tx-generic-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_LRO, "rx-lro"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_NTUPLE, "rx-ntuple-filter"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX, "rx-checksum"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RXHASH, "rx-hashing"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RXVLAN, "rx-vlan-hw-parse"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TXVLAN, "tx-vlan-hw-insert"),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/* names of features, as known by kernel. */
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_ESP_HW_OFFLOAD, "esp-hw-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_ESP_TX_CSUM_HW_OFFLOAD, "esp-tx-csum-hw-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_FCOE_MTU, "fcoe-mtu"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_HIGHDMA, "highdma"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_HW_TC_OFFLOAD, "hw-tc-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_L2_FWD_OFFLOAD, "l2-fwd-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_LOOPBACK, "loopback"),
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_MACSEC_HW_OFFLOAD, "macsec-hw-offload"),
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_ALL, "rx-all"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_FCS, "rx-fcs"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_GRO_HW, "rx-gro-hw"),
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_GRO_LIST, "rx-gro-list"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_UDP_GRO_FORWARDING, "rx-udp-gro-forwarding"),
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_UDP_TUNNEL_PORT_OFFLOAD, "rx-udp_tunnel-port-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_VLAN_FILTER, "rx-vlan-filter"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_VLAN_STAG_FILTER, "rx-vlan-stag-filter"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_RX_VLAN_STAG_HW_PARSE, "rx-vlan-stag-hw-parse"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TLS_HW_RECORD, "tls-hw-record"),
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TLS_HW_RX_OFFLOAD, "tls-hw-rx-offload"),
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TLS_HW_TX_OFFLOAD, "tls-hw-tx-offload"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_CHECKSUM_FCOE_CRC, "tx-checksum-fcoe-crc"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_CHECKSUM_IPV4, "tx-checksum-ipv4"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_CHECKSUM_IPV6, "tx-checksum-ipv6"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_CHECKSUM_IP_GENERIC, "tx-checksum-ip-generic"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_CHECKSUM_SCTP, "tx-checksum-sctp"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_ESP_SEGMENTATION, "tx-esp-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_FCOE_SEGMENTATION, "tx-fcoe-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_GRE_CSUM_SEGMENTATION, "tx-gre-csum-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_GRE_SEGMENTATION, "tx-gre-segmentation"),
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_GSO_LIST, "tx-gso-list"),
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_GSO_PARTIAL, "tx-gso-partial"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_GSO_ROBUST, "tx-gso-robust"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_IPXIP4_SEGMENTATION, "tx-ipxip4-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_IPXIP6_SEGMENTATION, "tx-ipxip6-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_NOCACHE_COPY, "tx-nocache-copy"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_SCATTER_GATHER, "tx-scatter-gather"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_SCATTER_GATHER_FRAGLIST, "tx-scatter-gather-fraglist"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_SCTP_SEGMENTATION, "tx-sctp-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_TCP6_SEGMENTATION, "tx-tcp6-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_TCP_ECN_SEGMENTATION, "tx-tcp-ecn-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_TCP_MANGLEID_SEGMENTATION, "tx-tcp-mangleid-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_TCP_SEGMENTATION, "tx-tcp-segmentation"),
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_TUNNEL_REMCSUM_SEGMENTATION,
"tx-tunnel-remcsum-segmentation"),
all/ethtool: add support for all currently supported kernel features As of upstream kernel v4.18-rc8. Note that we name the features like they are called in ethtool's ioctl API ETH_SS_FEATURES. Except, for features like "tx-gro", which ethtool utility aliases as "gro". So, for those features where ethtool has a built-in, alternative name, we prefer the alias. And again, note that a few aliases of ethtool utility ("sg", "tso", "tx") actually affect more than one underlying kernel feature. Note that 3 kernel features which are announced via ETH_SS_FEATURES are explicitly exluded because kernel marks them as "never_changed": #define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \ NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
2018-08-09 20:17:02 +02:00
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_UDP_SEGMENTATION, "tx-udp-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_UDP_TNL_CSUM_SEGMENTATION, "tx-udp_tnl-csum-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_UDP_TNL_SEGMENTATION, "tx-udp_tnl-segmentation"),
ETHT_FEAT(NM_ETHTOOL_ID_FEATURE_TX_VLAN_STAG_HW_INSERT, "tx-vlan-stag-hw-insert"),
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
};
/* the number of kernel features that we handle. It essentially is the sum of all
* kernel_names. So, all ethtool-ids that reference exactly one kernel-name
* (_NM_ETHTOOL_ID_FEATURE_NUM) + some extra, for ethtool-ids that are aliases
* for multiple kernel-names. */
#define N_ETHTOOL_KERNEL_FEATURES (((guint) _NM_ETHTOOL_ID_FEATURE_NUM) + 8u)
static void
_ASSERT_ethtool_feature_infos(void)
{
#if NM_MORE_ASSERTS > 10
guint i, k, n;
bool found[_NM_ETHTOOL_ID_FEATURE_NUM] = {};
G_STATIC_ASSERT_EXPR(G_N_ELEMENTS(_ethtool_feature_infos) == _NM_ETHTOOL_ID_FEATURE_NUM);
n = 0;
for (i = 0; i < G_N_ELEMENTS(_ethtool_feature_infos); i++) {
NMEthtoolFeatureState kstate;
const NMEthtoolFeatureInfo *inf = &_ethtool_feature_infos[i];
g_assert(inf->ethtool_id >= _NM_ETHTOOL_ID_FEATURE_FIRST);
g_assert(inf->ethtool_id <= _NM_ETHTOOL_ID_FEATURE_LAST);
g_assert(inf->n_kernel_names > 0);
for (k = 0; k < i; k++)
g_assert(inf->ethtool_id != _ethtool_feature_infos[k].ethtool_id);
ethtool: add and use _NM_ETHTOOL_ID_FEATURE_AS_IDX() macro
2020-05-14 21:20:05 +02:00
g_assert(!found[_NM_ETHTOOL_ID_FEATURE_AS_IDX(inf->ethtool_id)]);
found[_NM_ETHTOOL_ID_FEATURE_AS_IDX(inf->ethtool_id)] = TRUE;
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
kstate.idx_kernel_name = inf->n_kernel_names - 1;
g_assert((guint) kstate.idx_kernel_name == (guint)(inf->n_kernel_names - 1));
n += inf->n_kernel_names;
for (k = 0; k < inf->n_kernel_names; k++) {
ethtool: add more offload features that kernel supports New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
2021-01-27 13:50:48 +01:00
const char *name = inf->kernel_names[k];
g_assert(nm_utils_strv_find_first((char **) inf->kernel_names, k, name) < 0);
/* these offload features are only informational and cannot be set from user-space
* (NETIF_F_NEVER_CHANGE). We should not track them in _ethtool_feature_infos. */
g_assert(!nm_streq(name, "netns-local"));
g_assert(!nm_streq(name, "tx-lockless"));
g_assert(!nm_streq(name, "vlan-challenged"));
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
}
}
for (i = 0; i < _NM_ETHTOOL_ID_FEATURE_NUM; i++)
g_assert(found[i]);
g_assert(n == N_ETHTOOL_KERNEL_FEATURES);
#endif
}
static NMEthtoolFeatureStates *
ethtool_get_features(SocketHandle *shandle)
{
gs_free NMEthtoolFeatureStates * states = NULL;
gs_free struct ethtool_gstrings *ss_features = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
_ASSERT_ethtool_feature_infos();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
ss_features = ethtool_get_stringset(shandle, ETH_SS_FEATURES);
if (!ss_features)
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (ss_features->len > 0) {
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
gs_free struct ethtool_gfeatures * gfeatures_free = NULL;
struct ethtool_gfeatures * gfeatures;
gsize gfeatures_len;
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
guint idx;
const NMEthtoolFeatureState * states_list0 = NULL;
const NMEthtoolFeatureState *const *states_plist0 = NULL;
guint states_plist_n = 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
gfeatures_len = sizeof(struct ethtool_gfeatures)
+ (NM_DIV_ROUND_UP(ss_features->len, 32u) * sizeof(gfeatures->features[0]));
gfeatures = nm_malloc0_maybe_a(300, gfeatures_len, &gfeatures_free);
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
gfeatures->cmd = ETHTOOL_GFEATURES;
gfeatures->size = NM_DIV_ROUND_UP(ss_features->len, 32u);
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_handle(shandle, gfeatures, gfeatures_len) < 0)
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
for (idx = 0; idx < G_N_ELEMENTS(_ethtool_feature_infos); idx++) {
const NMEthtoolFeatureInfo *info = &_ethtool_feature_infos[idx];
guint idx_kernel_name;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
for (idx_kernel_name = 0; idx_kernel_name < info->n_kernel_names; idx_kernel_name++) {
NMEthtoolFeatureState *kstate;
const char * kernel_name = info->kernel_names[idx_kernel_name];
int i_feature;
guint i_block;
guint32 i_flag;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
i_feature = ethtool_gstrings_find(ss_features, kernel_name);
if (i_feature < 0)
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
i_block = ((guint) i_feature) / 32u;
i_flag = (guint32)(1u << (((guint) i_feature) % 32u));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (!states) {
states = g_malloc0(
sizeof(NMEthtoolFeatureStates)
+ (N_ETHTOOL_KERNEL_FEATURES * sizeof(NMEthtoolFeatureState))
+ ((N_ETHTOOL_KERNEL_FEATURES + G_N_ELEMENTS(_ethtool_feature_infos))
* sizeof(NMEthtoolFeatureState *)));
states_list0 = &states->states_list[0];
states_plist0 = (gpointer) &states_list0[N_ETHTOOL_KERNEL_FEATURES];
states->n_ss_features = ss_features->len;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_assert(states->n_states < N_ETHTOOL_KERNEL_FEATURES);
kstate = (NMEthtoolFeatureState *) &states_list0[states->n_states];
states->n_states++;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
kstate->info = info;
kstate->idx_ss_features = i_feature;
kstate->idx_kernel_name = idx_kernel_name;
kstate->available = !!(gfeatures->features[i_block].available & i_flag);
kstate->requested = !!(gfeatures->features[i_block].requested & i_flag);
kstate->active = !!(gfeatures->features[i_block].active & i_flag);
kstate->never_changed = !!(gfeatures->features[i_block].never_changed & i_flag);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_assert(states_plist_n
< N_ETHTOOL_KERNEL_FEATURES + G_N_ELEMENTS(_ethtool_feature_infos));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
ethtool: add and use _NM_ETHTOOL_ID_FEATURE_AS_IDX() macro
2020-05-14 21:20:05 +02:00
if (!states->states_indexed[_NM_ETHTOOL_ID_FEATURE_AS_IDX(info->ethtool_id)])
states->states_indexed[_NM_ETHTOOL_ID_FEATURE_AS_IDX(info->ethtool_id)] =
&states_plist0[states_plist_n];
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
((const NMEthtoolFeatureState **) states_plist0)[states_plist_n] = kstate;
states_plist_n++;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
ethtool: add and use _NM_ETHTOOL_ID_FEATURE_AS_IDX() macro
2020-05-14 21:20:05 +02:00
if (states && states->states_indexed[_NM_ETHTOOL_ID_FEATURE_AS_IDX(info->ethtool_id)]) {
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_assert(states_plist_n
< N_ETHTOOL_KERNEL_FEATURES + G_N_ELEMENTS(_ethtool_feature_infos));
nm_assert(!states_plist0[states_plist_n]);
states_plist_n++;
}
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
return g_steal_pointer(&states);
}
NMEthtoolFeatureStates *
nmp_utils_ethtool_get_features(int ifindex)
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
NMEthtoolFeatureStates * features;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
g_return_val_if_fail(ifindex > 0, 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
features = ethtool_get_features(&shandle);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (!features) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure getting features",
ifindex,
"get-features");
return NULL;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: retrieved kernel features",
ifindex,
"get-features");
return features;
}
static const char *
_ethtool_feature_state_to_string(char * buf,
gsize buf_size,
const NMEthtoolFeatureState *s,
const char * prefix)
{
int l;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
l = g_snprintf(buf,
buf_size,
"%s %s%s",
prefix ?: "",
ONOFF(s->active),
(!s->available || s->never_changed)
? ", [fixed]"
: ((s->requested != s->active)
? (s->requested ? ", [requested on]" : ", [requested off]")
: ""));
nm_assert(l < buf_size);
return buf;
}
gboolean
nmp_utils_ethtool_set_features(
int ifindex,
const NMEthtoolFeatureStates *features,
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
const NMOptionBool *requested /* indexed by NMEthtoolID - _NM_ETHTOOL_ID_FEATURE_FIRST */,
gboolean do_set /* or reset */)
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
gs_free struct ethtool_sfeatures * sfeatures_free = NULL;
struct ethtool_sfeatures * sfeatures;
gsize sfeatures_len;
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
int r;
guint i, j;
struct {
const NMEthtoolFeatureState *f_state;
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
NMOptionBool requested;
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
} set_states[N_ETHTOOL_KERNEL_FEATURES];
guint set_states_n = 0;
gboolean success = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
g_return_val_if_fail(ifindex > 0, 0);
g_return_val_if_fail(features, 0);
g_return_val_if_fail(requested, 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_assert(features->n_states <= N_ETHTOOL_KERNEL_FEATURES);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
for (i = 0; i < _NM_ETHTOOL_ID_FEATURE_NUM; i++) {
const NMEthtoolFeatureState *const *states_indexed;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
if (requested[i] == NM_OPTION_BOOL_DEFAULT)
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (!(states_indexed = features->states_indexed[i])) {
if (do_set) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: set feature %s: skip (not found)",
ifindex,
"set-features",
nm_ethtool_data[i + _NM_ETHTOOL_ID_FEATURE_FIRST]->optname);
success = FALSE;
}
continue;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
for (j = 0; states_indexed[j]; j++) {
const NMEthtoolFeatureState *s = states_indexed[j];
char sbuf[255];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (set_states_n >= G_N_ELEMENTS(set_states))
g_return_val_if_reached(FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (s->never_changed) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: %s feature %s (%s): %s, %s (skip feature marked as "
"never changed)",
ifindex,
"set-features",
do_set ? "set" : "reset",
nm_ethtool_data[i + _NM_ETHTOOL_ID_FEATURE_FIRST]->optname,
s->info->kernel_names[s->idx_kernel_name],
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
ONOFF(do_set ? requested[i] == NM_OPTION_BOOL_TRUE : s->active),
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
_ethtool_feature_state_to_string(sbuf,
sizeof(sbuf),
s,
do_set ? " currently:" : " before:"));
continue;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: %s feature %s (%s): %s, %s",
ifindex,
"set-features",
do_set ? "set" : "reset",
nm_ethtool_data[i + _NM_ETHTOOL_ID_FEATURE_FIRST]->optname,
s->info->kernel_names[s->idx_kernel_name],
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
ONOFF(do_set ? requested[i] == NM_OPTION_BOOL_TRUE : s->active),
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
_ethtool_feature_state_to_string(sbuf,
sizeof(sbuf),
s,
do_set ? " currently:" : " before:"));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (do_set && (!s->available || s->never_changed)
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
&& (s->active != (requested[i] == NM_OPTION_BOOL_TRUE))) {
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/* we request to change a flag which kernel reported as fixed.
* While the ethtool operation will silently succeed, mark the request
* as failure. */
success = FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
set_states[set_states_n].f_state = s;
set_states[set_states_n].requested = requested[i];
set_states_n++;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (set_states_n == 0) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: no feature requested",
ifindex,
"set-features");
return TRUE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
sfeatures_len =
sizeof(struct ethtool_sfeatures)
+ (NM_DIV_ROUND_UP(features->n_ss_features, 32U) * sizeof(sfeatures->features[0]));
sfeatures = nm_malloc0_maybe_a(300, sfeatures_len, &sfeatures_free);
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
sfeatures->cmd = ETHTOOL_SFEATURES;
sfeatures->size = NM_DIV_ROUND_UP(features->n_ss_features, 32U);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
for (i = 0; i < set_states_n; i++) {
const NMEthtoolFeatureState *s = set_states[i].f_state;
guint i_block;
guint32 i_flag;
gboolean is_requested;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
i_block = s->idx_ss_features / 32u;
i_flag = (guint32)(1u << (s->idx_ss_features % 32u));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
sfeatures->features[i_block].valid |= i_flag;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (do_set)
platform: use NMOptionBool instead of NMTernary NMTernary is a dependency for libnm-core. Avoid it.
2021-01-10 16:51:37 +01:00
is_requested = (set_states[i].requested == NM_OPTION_BOOL_TRUE);
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
else
is_requested = s->active;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
if (is_requested)
sfeatures->features[i_block].requested |= i_flag;
else
sfeatures->features[i_block].requested &= ~i_flag;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
r = _ethtool_call_handle(&shandle, sfeatures, sfeatures_len);
if (r < 0) {
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
success = FALSE;
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure setting features (%s)",
ifindex,
"set-features",
all: replace g_strerror() calls with nm_strerror_native()
2019-01-31 17:08:03 +01:00
nm_strerror_native(-r));
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: %s",
ifindex,
"set-features",
success ? "successfully setting features"
docs: misc. typos Found via `codespell -q 3 --skip="*.po"` https://github.com/NetworkManager/NetworkManager/pull/203
2018-09-14 23:49:20 -04:00
: "at least some of the features were not successfully set");
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
return success;
}
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
static gboolean
ethtool_get_coalesce(SocketHandle *shandle, NMEthtoolCoalesceState *coalesce)
{
struct ethtool_coalesce eth_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
eth_data.cmd = ETHTOOL_GCOALESCE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
if (_ethtool_call_handle(shandle, &eth_data, sizeof(struct ethtool_coalesce)) != 0)
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: make states of NMEthtoolCoalesceState indexed by ethtool_id We already have NMEthtoolID to handle coalesce options in a way that is convenient programmatically. That is, we can iterate over all valid coalesce options (it's just an integer) and use that in a more generic way. If NMEthtoolCoalesceState names all fields explicitly, we need explicit code that names each coalesce option. Especially since NMEthtoolCoalesceState is an internal and intermediate data structure, this is cumbersome and unnecessary. Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a NMPlatform argument without actually needing it. nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform instance, and should not have the appearance of being a method of NMPlatform.
2020-05-14 09:16:31 +02:00
*coalesce = (NMEthtoolCoalesceState){
.s = {
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS)] =
eth_data.rx_coalesce_usecs,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES)] =
eth_data.rx_max_coalesced_frames,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_IRQ)] =
eth_data.rx_coalesce_usecs_irq,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_IRQ)] =
eth_data.rx_max_coalesced_frames_irq,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS)] =
eth_data.tx_coalesce_usecs,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES)] =
eth_data.tx_max_coalesced_frames,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_IRQ)] =
eth_data.tx_coalesce_usecs_irq,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_IRQ)] =
eth_data.tx_max_coalesced_frames_irq,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_STATS_BLOCK_USECS)] =
eth_data.stats_block_coalesce_usecs,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_ADAPTIVE_RX)] =
eth_data.use_adaptive_rx_coalesce,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_ADAPTIVE_TX)] =
eth_data.use_adaptive_tx_coalesce,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_PKT_RATE_LOW)] =
eth_data.pkt_rate_low,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_LOW)] =
eth_data.rx_coalesce_usecs_low,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_LOW)] =
eth_data.rx_max_coalesced_frames_low,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_LOW)] =
eth_data.tx_coalesce_usecs_low,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_LOW)] =
eth_data.tx_max_coalesced_frames_low,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_PKT_RATE_HIGH)] =
eth_data.pkt_rate_high,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_HIGH)] =
eth_data.rx_coalesce_usecs_high,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_HIGH)] =
eth_data.rx_max_coalesced_frames_high,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_HIGH)] =
eth_data.tx_coalesce_usecs_high,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_HIGH)] =
eth_data.tx_max_coalesced_frames_high,
[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_SAMPLE_INTERVAL)] =
eth_data.rate_sample_interval,
}};
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
return TRUE;
}
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
gboolean
nmp_utils_ethtool_get_coalesce(int ifindex, NMEthtoolCoalesceState *coalesce)
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
{
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
g_return_val_if_fail(ifindex > 0, FALSE);
g_return_val_if_fail(coalesce, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
if (!ethtool_get_coalesce(&shandle, coalesce)) {
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure getting coalesce settings",
ifindex,
"get-coalesce");
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
return FALSE;
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: retrieved kernel coalesce settings",
ifindex,
"get-coalesce");
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
return TRUE;
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
}
static gboolean
ethtool_set_coalesce(SocketHandle *shandle, const NMEthtoolCoalesceState *coalesce)
{
struct ethtool_coalesce eth_data;
platform: make states of NMEthtoolCoalesceState indexed by ethtool_id We already have NMEthtoolID to handle coalesce options in a way that is convenient programmatically. That is, we can iterate over all valid coalesce options (it's just an integer) and use that in a more generic way. If NMEthtoolCoalesceState names all fields explicitly, we need explicit code that names each coalesce option. Especially since NMEthtoolCoalesceState is an internal and intermediate data structure, this is cumbersome and unnecessary. Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a NMPlatform argument without actually needing it. nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform instance, and should not have the appearance of being a method of NMPlatform.
2020-05-14 09:16:31 +02:00
gboolean success;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: make states of NMEthtoolCoalesceState indexed by ethtool_id We already have NMEthtoolID to handle coalesce options in a way that is convenient programmatically. That is, we can iterate over all valid coalesce options (it's just an integer) and use that in a more generic way. If NMEthtoolCoalesceState names all fields explicitly, we need explicit code that names each coalesce option. Especially since NMEthtoolCoalesceState is an internal and intermediate data structure, this is cumbersome and unnecessary. Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a NMPlatform argument without actually needing it. nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform instance, and should not have the appearance of being a method of NMPlatform.
2020-05-14 09:16:31 +02:00
nm_assert(shandle);
nm_assert(coalesce);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
eth_data = (struct ethtool_coalesce){
.cmd = ETHTOOL_SCOALESCE,
platform: make states of NMEthtoolCoalesceState indexed by ethtool_id We already have NMEthtoolID to handle coalesce options in a way that is convenient programmatically. That is, we can iterate over all valid coalesce options (it's just an integer) and use that in a more generic way. If NMEthtoolCoalesceState names all fields explicitly, we need explicit code that names each coalesce option. Especially since NMEthtoolCoalesceState is an internal and intermediate data structure, this is cumbersome and unnecessary. Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a NMPlatform argument without actually needing it. nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform instance, and should not have the appearance of being a method of NMPlatform.
2020-05-14 09:16:31 +02:00
.rx_coalesce_usecs =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS)],
.rx_max_coalesced_frames =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES)],
.rx_coalesce_usecs_irq =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_IRQ)],
.rx_max_coalesced_frames_irq =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_IRQ)],
.tx_coalesce_usecs =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS)],
.tx_max_coalesced_frames =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES)],
.tx_coalesce_usecs_irq =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_IRQ)],
.tx_max_coalesced_frames_irq =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_IRQ)],
.stats_block_coalesce_usecs =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_STATS_BLOCK_USECS)],
.use_adaptive_rx_coalesce =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_ADAPTIVE_RX)],
.use_adaptive_tx_coalesce =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_ADAPTIVE_TX)],
.pkt_rate_low =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_PKT_RATE_LOW)],
.rx_coalesce_usecs_low =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_LOW)],
.rx_max_coalesced_frames_low =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_LOW)],
.tx_coalesce_usecs_low =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_LOW)],
.tx_max_coalesced_frames_low =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_LOW)],
.pkt_rate_high =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_PKT_RATE_HIGH)],
.rx_coalesce_usecs_high =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_USECS_HIGH)],
.rx_max_coalesced_frames_high =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_RX_FRAMES_HIGH)],
.tx_coalesce_usecs_high =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_USECS_HIGH)],
.tx_max_coalesced_frames_high =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_TX_FRAMES_HIGH)],
.rate_sample_interval =
coalesce->s[_NM_ETHTOOL_ID_COALESCE_AS_IDX(NM_ETHTOOL_ID_COALESCE_SAMPLE_INTERVAL)],
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
success = (_ethtool_call_handle(shandle, &eth_data, sizeof(struct ethtool_coalesce)) == 0);
return success;
}
gboolean
nmp_utils_ethtool_set_coalesce(int ifindex, const NMEthtoolCoalesceState *coalesce)
{
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
g_return_val_if_fail(ifindex > 0, FALSE);
g_return_val_if_fail(coalesce, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
if (!ethtool_set_coalesce(&shandle, coalesce)) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure setting coalesce settings",
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
ifindex,
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
"set-coalesce");
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: set kernel coalesce settings",
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
ifindex,
platform: simplify NMEthtoolCoalesceState to only track one state Only in one moment we need the old and requested settings together: during _ethtool_coalesce_set(). But for that we shouldn't track both states in "NMEthtoolCoalesceState". Simplify "NMEthtoolCoalesceState" to only contain one set of options. By tracking less state, the code becomes simpler, because you don't need to wonder where the old and requested state is used.
2020-05-14 09:16:30 +02:00
"set-coalesce");
platform: add support for coalesce settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-07 17:11:34 +02:00
return TRUE;
}
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
static gboolean
ethtool_get_ring(SocketHandle *shandle, NMEthtoolRingState *ring)
{
struct ethtool_ringparam eth_data;
eth_data.cmd = ETHTOOL_GRINGPARAM;
if (_ethtool_call_handle(shandle, &eth_data, sizeof(struct ethtool_ringparam)) != 0)
return FALSE;
ring->rx_pending = eth_data.rx_pending;
ring->rx_jumbo_pending = eth_data.rx_jumbo_pending;
ring->rx_mini_pending = eth_data.rx_mini_pending;
ring->tx_pending = eth_data.tx_pending;
return TRUE;
}
gboolean
nmp_utils_ethtool_get_ring(int ifindex, NMEthtoolRingState *ring)
{
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
g_return_val_if_fail(ifindex > 0, FALSE);
g_return_val_if_fail(ring, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
if (!ethtool_get_ring(&shandle, ring)) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure getting ring settings",
ifindex,
"get-ring");
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: retrieved kernel ring settings",
ifindex,
"get-ring");
return TRUE;
}
static gboolean
ethtool_set_ring(SocketHandle *shandle, const NMEthtoolRingState *ring)
{
gboolean success;
struct ethtool_ringparam eth_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
g_return_val_if_fail(shandle, FALSE);
g_return_val_if_fail(ring, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
eth_data = (struct ethtool_ringparam){
.cmd = ETHTOOL_SRINGPARAM,
.rx_pending = ring->rx_pending,
.rx_jumbo_pending = ring->rx_jumbo_pending,
.rx_mini_pending = ring->rx_mini_pending,
.tx_pending = ring->tx_pending,
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
success = (_ethtool_call_handle(shandle, &eth_data, sizeof(struct ethtool_ringparam)) == 0);
return success;
}
gboolean
nmp_utils_ethtool_set_ring(int ifindex, const NMEthtoolRingState *ring)
{
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
g_return_val_if_fail(ifindex > 0, FALSE);
g_return_val_if_fail(ring, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
if (!ethtool_set_ring(&shandle, ring)) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %s: failure setting ring settings",
ifindex,
"set-ring");
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add support for ring settings using ioctl() https://bugzilla.redhat.com/show_bug.cgi?id=1614700
2020-05-14 18:27:54 +02:00
nm_log_trace(LOGD_PLATFORM, "ethtool[%d]: %s: set kernel ring settings", ifindex, "set-ring");
return TRUE;
}
platform/ethtool: add code to get/set offload features via ethtool Also, add two more features "tx-tcp-segmentation" and "tx-tcp6-segmentation". There are two reasons for that: - systemd-networkd supports setting these two features, so lets support them too (apparently they are important enough for networkd). - these two features are already implicitly covered by "tso". Like for the "ethtool" program, "tso" is an alias for several actual features. By adding two features that are already also covered by an alias (which sets multiple kernel names at once), we showcase how aliases for the same feature can coexist. In particular, note how setting "tso on tx-tcp6-segmentation off" will behave as one would expect: all 4 tso features covered by the alias are enabled, except that particular one.
2018-07-16 15:42:07 +02:00
/*****************************************************************************/
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_get_driver_info(int ifindex, NMPUtilsEthtoolDriverInfo *data)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
platform: avoid copying arguments for nmp_utils_ethtool_get_driver_info() We call nmp_utils_ethtool_get_driver_info() twice when receiving a netlink message, but we don't need a clone of the string values. Instead, expose a data structure that should be stack allocated by the caller.
2016-12-12 13:47:52 +01:00
struct ethtool_drvinfo *drvinfo;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
G_STATIC_ASSERT_EXPR(sizeof(*data) == sizeof(*drvinfo));
G_STATIC_ASSERT_EXPR(offsetof(NMPUtilsEthtoolDriverInfo, driver)
== offsetof(struct ethtool_drvinfo, driver));
G_STATIC_ASSERT_EXPR(offsetof(NMPUtilsEthtoolDriverInfo, version)
== offsetof(struct ethtool_drvinfo, version));
G_STATIC_ASSERT_EXPR(offsetof(NMPUtilsEthtoolDriverInfo, fw_version)
== offsetof(struct ethtool_drvinfo, fw_version));
G_STATIC_ASSERT_EXPR(sizeof(data->driver) == sizeof(drvinfo->driver));
G_STATIC_ASSERT_EXPR(sizeof(data->version) == sizeof(drvinfo->version));
G_STATIC_ASSERT_EXPR(sizeof(data->fw_version) == sizeof(drvinfo->fw_version));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
platform: avoid copying arguments for nmp_utils_ethtool_get_driver_info() We call nmp_utils_ethtool_get_driver_info() twice when receiving a netlink message, but we don't need a clone of the string values. Instead, expose a data structure that should be stack allocated by the caller.
2016-12-12 13:47:52 +01:00
g_return_val_if_fail(data, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: avoid copying arguments for nmp_utils_ethtool_get_driver_info() We call nmp_utils_ethtool_get_driver_info() twice when receiving a netlink message, but we don't need a clone of the string values. Instead, expose a data structure that should be stack allocated by the caller.
2016-12-12 13:47:52 +01:00
drvinfo = (struct ethtool_drvinfo *) data;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
*drvinfo = (struct ethtool_drvinfo){
.cmd = ETHTOOL_GDRVINFO,
};
return _ethtool_call_once(ifindex, drvinfo, sizeof(*drvinfo)) >= 0;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
}
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_get_permanent_address(int ifindex, guint8 *buf, size_t *length)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
struct {
struct ethtool_perm_addr e;
shared: add duplicate for NM_UTILS_HWADDR_LEN_MAX to "nm-base/nm-base.h" We will need this in "shared/nm-platform", but we don't want to include "libnm-core/nm-utils.h" for that.
2021-01-08 18:45:16 +01:00
guint8 _extra_data[_NM_UTILS_HWADDR_LEN_MAX + 1];
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
} edata = {
.e.cmd = ETHTOOL_GPERMADDR,
shared: add duplicate for NM_UTILS_HWADDR_LEN_MAX to "nm-base/nm-base.h" We will need this in "shared/nm-platform", but we don't want to include "libnm-core/nm-utils.h" for that.
2021-01-08 18:45:16 +01:00
.e.size = _NM_UTILS_HWADDR_LEN_MAX,
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
};
platform: fix GCC warning about zero-length array in nmp_utils_ethtool_get_permanent_address() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’: src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds] 854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) { ./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’ Fix this warning.
2020-02-10 11:01:43 +01:00
const guint8 *pdata;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
platform: refactor comparing for all-zero,all-ones MAC address in nmp_utils_ethtool_get_permanent_address() Don't like the static fields. Also, don't assert against return values from the ethtool call. And check that the length is positive.
2016-05-20 17:53:58 +02:00
guint i;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
if (_ethtool_call_once(ifindex, &edata, sizeof(edata)) < 0)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return FALSE;
shared: add duplicate for NM_UTILS_HWADDR_LEN_MAX to "nm-base/nm-base.h" We will need this in "shared/nm-platform", but we don't want to include "libnm-core/nm-utils.h" for that.
2021-01-08 18:45:16 +01:00
if (edata.e.size > _NM_UTILS_HWADDR_LEN_MAX)
platform: refactor comparing for all-zero,all-ones MAC address in nmp_utils_ethtool_get_permanent_address() Don't like the static fields. Also, don't assert against return values from the ethtool call. And check that the length is positive.
2016-05-20 17:53:58 +02:00
return FALSE;
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
if (edata.e.size < 1)
platform: don't accept 00:00:00:00:00:00 as valid permanent address In nmp_utils_ethtool_get_permanent_address(), don' accept a permanent address of all zeros. https://bugzilla.redhat.com/show_bug.cgi?id=1264024
2015-09-17 19:53:56 +02:00
return FALSE;
platform: fix GCC warning about zero-length array in nmp_utils_ethtool_get_permanent_address() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’: src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds] 854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) { ./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’ Fix this warning.
2020-02-10 11:01:43 +01:00
pdata = (const guint8 *) edata.e.data;
if (NM_IN_SET(pdata[0], 0, 0xFF)) {
platform: refactor comparing for all-zero,all-ones MAC address in nmp_utils_ethtool_get_permanent_address() Don't like the static fields. Also, don't assert against return values from the ethtool call. And check that the length is positive.
2016-05-20 17:53:58 +02:00
/* Some drivers might return a permanent address of all zeros.
* Reject that (rh#1264024)
*
* Some drivers return a permanent address of all ones. Reject that too */
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
for (i = 1; i < edata.e.size; i++) {
platform: fix GCC warning about zero-length array in nmp_utils_ethtool_get_permanent_address() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’: src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds] 854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) { ./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’ Fix this warning.
2020-02-10 11:01:43 +01:00
if (pdata[0] != pdata[i])
platform: refactor comparing for all-zero,all-ones MAC address in nmp_utils_ethtool_get_permanent_address() Don't like the static fields. Also, don't assert against return values from the ethtool call. And check that the length is positive.
2016-05-20 17:53:58 +02:00
goto not_all_0or1;
}
platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF) Drivers are stupid, and just like the platform ignores an all zeros permanent address, so should it ignore all ones. NetworkManager[509]: <debug> [1453743778.854919] [devices/nm-device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.855438] [devices/nm-device.c:9138] constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.861602] [devices/nm-device.c:9148] constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
2016-01-26 11:33:49 -06:00
return FALSE;
platform: refactor comparing for all-zero,all-ones MAC address in nmp_utils_ethtool_get_permanent_address() Don't like the static fields. Also, don't assert against return values from the ethtool call. And check that the length is positive.
2016-05-20 17:53:58 +02:00
}
platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF) Drivers are stupid, and just like the platform ignores an all zeros permanent address, so should it ignore all ones. NetworkManager[509]: <debug> [1453743778.854919] [devices/nm-device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.855438] [devices/nm-device.c:9138] constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx NetworkManager[509]: <debug> [1453743778.861602] [devices/nm-device.c:9148] constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
2016-01-26 11:33:49 -06:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
not_all_0or1:
platform: fix GCC warning about zero-length array in nmp_utils_ethtool_get_permanent_address() GCC 10 complains about accesses to elements of zero-length arrays that overlap other members of the same object: src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’: src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds] 854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) { ./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’ Fix this warning.
2020-02-10 11:01:43 +01:00
memcpy(buf, pdata, edata.e.size);
Revert "platform: fix GCC warning about zero-lenght array (2)" This reverts commit 5076fc0ca0e22b3db7987df561922d9efa840f26.
2020-02-10 10:57:10 +01:00
*length = edata.e.size;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return TRUE;
}
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_supports_carrier_detect(int ifindex)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
struct ethtool_cmd edata = {.cmd = ETHTOOL_GLINK};
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
/* We ignore the result. If the ETHTOOL_GLINK call succeeded, then we
* assume the device supports carrier-detect, otherwise we assume it
* doesn't.
*/
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
return _ethtool_call_once(ifindex, &edata, sizeof(edata)) >= 0;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
}
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_supports_vlans(int ifindex)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
gs_free struct ethtool_gfeatures * features_free = NULL;
struct ethtool_gfeatures * features;
gsize features_len;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
int idx, block, bit, size;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
idx = ethtool_get_stringset_index(&shandle, ETH_SS_FEATURES, "vlan-challenged");
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
if (idx < 0) {
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
nm_log_dbg(LOGD_PLATFORM,
"ethtool[%d]: vlan-challenged ethtool feature does not exist?",
ifindex);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
block = idx / 32;
bit = idx % 32;
size = block + 1;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
features_len = sizeof(*features) + (size * sizeof(struct ethtool_get_features_block));
features = nm_malloc0_maybe_a(300, features_len, &features_free);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
features->cmd = ETHTOOL_GFEATURES;
features->size = size;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_handle(&shandle, features, features_len) < 0)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return !(features->features[block].active & (1 << bit));
}
int
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_get_peer_ifindex(int ifindex)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
gsize stats_len;
gs_free struct ethtool_stats * stats_free = NULL;
struct ethtool_stats * stats;
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
int peer_ifindex_stat;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
peer_ifindex_stat = ethtool_get_stringset_index(&shandle, ETH_SS_STATS, "peer_ifindex");
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
if (peer_ifindex_stat < 0) {
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
nm_log_dbg(LOGD_PLATFORM, "ethtool[%d]: peer_ifindex stat does not exist?", ifindex);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
stats_len = sizeof(*stats) + (peer_ifindex_stat + 1) * sizeof(guint64);
stats = nm_malloc0_maybe_a(300, stats_len, &stats_free);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
stats->cmd = ETHTOOL_GSTATS;
stats->n_stats = peer_ifindex_stat + 1;
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_handle(&shandle, stats, stats_len) < 0)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return stats->data[peer_ifindex_stat];
}
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_get_wake_on_lan(int ifindex)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
struct ethtool_wolinfo wol = {
.cmd = ETHTOOL_GWOL,
};
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_once(ifindex, &wol, sizeof(wol)) < 0)
platform: move ethtool_*() to nmp_utils_ethtool_*()
2015-05-02 07:59:59 +02:00
return FALSE;
return wol.wolopts != 0;
}
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_get_link_settings(int ifindex,
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
gboolean * out_autoneg,
guint32 * out_speed,
NMPlatformLinkDuplexType *out_duplex)
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
{
struct ethtool_cmd edata = {
.cmd = ETHTOOL_GSET,
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_once(ifindex, &edata, sizeof(edata)) < 0)
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
NM_SET_OUT(out_autoneg, (edata.autoneg == AUTONEG_ENABLE));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
if (out_speed) {
guint32 speed;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
speed = ethtool_cmd_speed(&edata);
if (speed == G_MAXUINT16 || speed == G_MAXUINT32)
speed = 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
*out_speed = speed;
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
if (out_duplex) {
switch (edata.duplex) {
case DUPLEX_HALF:
*out_duplex = NM_PLATFORM_LINK_DUPLEX_HALF;
break;
case DUPLEX_FULL:
*out_duplex = NM_PLATFORM_LINK_DUPLEX_FULL;
break;
default: /* DUPLEX_UNKNOWN */
*out_duplex = NM_PLATFORM_LINK_DUPLEX_UNKNOWN;
break;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move ethtool_get_link_speed() to nm-platform-utils
2015-06-01 12:06:12 +02:00
return TRUE;
}
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
#define ADVERTISED_INVALID 0
#define BASET_ALL_MODES \
(ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | ADVERTISED_100baseT_Half \
| ADVERTISED_100baseT_Full | ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full \
| ADVERTISED_10000baseT_Full)
all: don't use "static inline" in source files For static functions inside a module, the compiler determines on its own whether to inline the function. Also, "inline" was used at some places that don't immediatly look like candidates for inlining. It was most likely a copy&paste error.
2019-02-06 09:04:23 +01:00
static guint32
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
get_baset_mode(guint32 speed, NMPlatformLinkDuplexType duplex)
{
if (duplex == NM_PLATFORM_LINK_DUPLEX_UNKNOWN)
return ADVERTISED_INVALID;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
if (duplex == NM_PLATFORM_LINK_DUPLEX_HALF) {
switch (speed) {
case 10:
return ADVERTISED_10baseT_Half;
case 100:
return ADVERTISED_100baseT_Half;
case 1000:
return ADVERTISED_1000baseT_Half;
default:
return ADVERTISED_INVALID;
}
} else {
switch (speed) {
case 10:
return ADVERTISED_10baseT_Full;
case 100:
return ADVERTISED_100baseT_Full;
case 1000:
return ADVERTISED_1000baseT_Full;
case 10000:
return ADVERTISED_10000baseT_Full;
default:
return ADVERTISED_INVALID;
}
}
}
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_ethtool_set_link_settings(int ifindex,
gboolean autoneg,
guint32 speed,
NMPlatformLinkDuplexType duplex)
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
struct ethtool_cmd edata = {
.cmd = ETHTOOL_GSET,
};
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
g_return_val_if_fail((speed && duplex != NM_PLATFORM_LINK_DUPLEX_UNKNOWN)
|| (!speed && duplex == NM_PLATFORM_LINK_DUPLEX_UNKNOWN),
FALSE);
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
/* retrieve first current settings */
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
if (_ethtool_call_handle(&shandle, &edata, sizeof(edata)) < 0)
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
return FALSE;
platform/trivial: add FIXME comment to use new ethtool API to set link settings
2018-09-06 10:29:43 +02:00
/* FIXME: try first new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f1ac7a700d039c61d8d8b99f28d605d489a60cf
*/
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
/* then change the needed ones */
edata.cmd = ETHTOOL_SSET;
if (autoneg) {
edata.autoneg = AUTONEG_ENABLE;
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
if (!speed)
edata.advertising = edata.supported;
else {
guint32 mode;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
mode = get_baset_mode(speed, duplex);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: allow to force the advertised auto-negotiation link value This will only work for network devices supporting the BASE-T specification.
2018-06-12 12:57:05 +02:00
if (!mode) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: %uBASE-T %s duplex mode cannot be advertised",
ifindex,
speed,
nm_platform_link_duplex_type_to_string(duplex));
return FALSE;
}
if (!(edata.supported & mode)) {
nm_log_trace(LOGD_PLATFORM,
"ethtool[%d]: device does not support %uBASE-T %s duplex mode",
ifindex,
speed,
nm_platform_link_duplex_type_to_string(duplex));
return FALSE;
}
edata.advertising = (edata.supported & ~BASET_ALL_MODES) | mode;
}
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
} else {
edata.autoneg = AUTONEG_DISABLE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
if (speed)
ethtool_cmd_speed_set(&edata, speed);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
switch (duplex) {
case NM_PLATFORM_LINK_DUPLEX_HALF:
edata.duplex = DUPLEX_HALF;
break;
case NM_PLATFORM_LINK_DUPLEX_FULL:
edata.duplex = DUPLEX_FULL;
break;
core: merge NM_PLATFORM_LINK_DUPLEX_UNSET and UNKNOWN They have basically the same use, except that certain places handled one but not the other.
2016-11-22 12:59:11 +01:00
case NM_PLATFORM_LINK_DUPLEX_UNKNOWN:
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
break;
core: merge NM_PLATFORM_LINK_DUPLEX_UNSET and UNKNOWN They have basically the same use, except that certain places handled one but not the other.
2016-11-22 12:59:11 +01:00
default:
g_return_val_if_reached(FALSE);
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
return _ethtool_call_handle(&shandle, &edata, sizeof(edata)) >= 0;
platform: add APIs to allow link negotiation management Added platform functions to retrieve device link mode status and to switch from auto to manual link negotiation: nm_platform_ethtool_get_link_settings nm_platform_ethtool_set_link_settings
2016-09-10 16:48:01 +02:00
}
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
gboolean
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
nmp_utils_ethtool_set_wake_on_lan(int ifindex,
_NMSettingWiredWakeOnLan wol,
const char * wol_password)
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
struct ethtool_wolinfo wol_info = {
.cmd = ETHTOOL_SWOL,
.wolopts = 0,
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (wol == _NM_SETTING_WIRED_WAKE_ON_LAN_IGNORE)
wake-on-lan: add option to keep existing settings Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables management of wake-on-lan by NetworkManager (i.e. the pre-existing option will not be touched). Also, change the default behavior to be 'ignore' instead of 'disabled'. https://bugzilla.gnome.org/show_bug.cgi?id=755182
2015-09-21 18:24:07 +02:00
return TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
nm_log_dbg(LOGD_PLATFORM,
"ethtool[%d]: setting Wake-on-LAN options 0x%x, password '%s'",
ifindex,
(unsigned) wol,
wol_password);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_PHY))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_PHY;
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_UNICAST))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_UCAST;
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_MULTICAST))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_MCAST;
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_BROADCAST))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_BCAST;
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_ARP))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_ARP;
platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platform Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
2021-01-08 17:01:45 +01:00
if (NM_FLAGS_HAS(wol, _NM_SETTING_WIRED_WAKE_ON_LAN_MAGIC))
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
wol_info.wolopts |= WAKE_MAGIC;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
if (wol_password) {
shared: add _nm_utils_hwaddr_aton_exact() This is the same as libnm's nm_utils_hwaddr_aton(), which however is public API. We want to use this function also without libnm(-core). Hence add the helper to "shared/nm-glib-aux".
2021-01-08 19:01:28 +01:00
if (!_nm_utils_hwaddr_aton_exact(wol_password, wol_info.sopass, ETH_ALEN)) {
platform/ethtool: add SocketHandle to reuse socket for ethtool requests Previously, each call to ethtool_get() would resolve the ifindex and create a new socket for the ethtool request. This is partly done, because ethtool only supports making requests by name. Since interfaces can be renamed, this is inherrently racy. So, we want to fetch the latest name shortly before making the request. Some functions like nmp_utils_ethtool_supports_vlans() require multiple ioctls. And next, we will introduce more ethtool functions, that make an even larger number of individual requests. Add a simple SocketHandle struct, to create the socket once and reuse it for multiple requests. This is still entirely internal API in "nm-platform-utils.c".
2018-07-16 13:08:38 +02:00
nm_log_dbg(LOGD_PLATFORM,
"ethtool[%d]: couldn't parse Wake-on-LAN password '%s'",
ifindex,
wol_password);
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
return FALSE;
}
wol_info.wolopts |= WAKE_MAGICSECURE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
return _ethtool_call_once(ifindex, &wol_info, sizeof(wol_info)) >= 0;
core: configure Wake-on-LAN parameters for Ethernet devices
2015-05-12 14:44:03 +02:00
}
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/******************************************************************************
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
* mii
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
*****************************************************************************/
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
gboolean
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
nmp_utils_mii_supports_carrier_detect(int ifindex)
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
{
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
nm_auto_socket_handle SocketHandle shandle = SOCKET_HANDLE_INIT(ifindex);
platform/mii: use SocketHandle also for nmp_utils_mii_supports_carrier_detect() There is little difference in practice because there is only one caller. Still re-use the SocketHandle also for mii. If only, to make it clear that SocketHandle is not only suitable for ethtool, but also mii.
2018-07-16 14:11:09 +02:00
int r;
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
struct ifreq ifr;
struct mii_ioctl_data * mii;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
g_return_val_if_fail(ifindex > 0, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
r = _ioctl_call("mii",
"SIOCGMIIPHY",
SIOCGMIIPHY,
shandle.ifindex,
&shandle.fd,
shandle.ifname,
IOCTL_CALL_DATA_TYPE_NONE,
NULL,
0,
&ifr);
if (r < 0)
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
/* If we can read the BMSR register, we assume that the card supports MII link detection */
mii = (struct mii_ioctl_data *) &ifr.ifr_ifru;
mii->reg_num = MII_BMSR;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
r = _ioctl_call("mii",
"SIOCGMIIREG",
SIOCGMIIREG,
shandle.ifindex,
&shandle.fd,
shandle.ifname,
IOCTL_CALL_DATA_TYPE_IFRU,
mii,
sizeof(*mii),
&ifr);
if (r < 0)
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii ethtool/mii API is based on the ifname. As an interface can be renamed, this API is inherently racy. We would prefer to use the ifindex instead. The ifindex of a device cannot change (altough it can repeat, which opens a different race *sigh*). Anyway, we were already trying to minimize the race be resolving the name from ifindex immediately before the call to ethtool/mii. Do better than that. Now resolve the name before and after the call. If the name changed in the meantime, we have an indication that a race might have happend (but we cannot be sure). Note that this can not catch every possible kind of rename race. If you are very unlucky a swapping of names cannot be detected. For getters this is relatively straight forward. Just retry when we have an indication to fall victim to a race (up to a few times). Yes, we still cannot be 100% sure, but this should be very reliable in practice. For setters (that modify the device) we also retry. We do so under the assumption that setting the same options multiple times has no bad effect. Note that for setters the race of swapping interface names is particularly bad. If we hit a very unlucky race condition, we might set the setting on the wrong interface and there is nothing we can do about it. The retry only ensures that eventually we will set it on the right interface. Note that this involves one more if_indextoname() call for each operation (in the common case when there is no renaming race). In cases where we make multiple ioctl calls, we cache and reuse the information though. So, for such calls the overhead is even smaller.
2019-05-02 17:13:51 +02:00
mii = (struct mii_ioctl_data *) &ifr.ifr_ifru;
platform/mii: use SocketHandle also for nmp_utils_mii_supports_carrier_detect() There is little difference in practice because there is only one caller. Still re-use the SocketHandle also for mii. If only, to make it clear that SocketHandle is not only suitable for ethtool, but also mii.
2018-07-16 14:11:09 +02:00
nm_log_trace(LOGD_PLATFORM,
"mii[%d,%s]: carrier-detect yes: SIOCGMIIREG result 0x%X",
ifindex,
shandle.ifname,
mii->val_out);
platform: lookup ifname for ethtool/mii ioctl immediately before use The ioctl APIs ethtool/mii require an interface ifname. That is inherrently racy as interfaces can be renamed. This cannot be fixed, we can only minimize the time between verifying the ifname and calling ioctl. We already had problems with that when ethtool would access an interface by name that didn't exists. See commit ab41c13b0611c6cc967b055d328637a143b5c59b . Checking for an existing interface only helps avoiding races when an interface gets deleted. It does not help against renaming. Go one step further, and instead of checking whether such an ifname exists, try to get the ifname based on the ifindex immediately before we need it. This brings an additional overhead for each ethtool access.
2016-12-11 22:46:14 +01:00
return TRUE;
platform: move supports_mii_carrier_detect() to nmp_utils_mii_supports_carrier_detect()
2015-05-03 12:49:46 +02:00
}
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
/******************************************************************************
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
* udev
platform/ethtool: split functions for ETHTOOL_GSTRINGS ethtool_get_stringset() will be used later, independently. Also, don't trust and ensure that the block of strings returned by ETHTOOL_GSTRINGS are NUL terminated.
2018-07-16 10:43:28 +02:00
*****************************************************************************/
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
const char *
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
nmp_utils_udev_get_driver(struct udev_device *udevice)
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
{
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
struct udev_device *parent = NULL, *grandparent = NULL;
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
const char * driver, *subsys;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
driver = udev_device_get_driver(udevice);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
if (driver)
goto out;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
/* Try the parent */
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
parent = udev_device_get_parent(udevice);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
if (parent) {
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
driver = udev_device_get_driver(parent);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
if (!driver) {
/* Try the grandparent if it's an ibmebus device or if the
* subsys is NULL which usually indicates some sort of
* platform device like a 'gadget' net interface.
*/
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
subsys = udev_device_get_subsystem(parent);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
if ((g_strcmp0(subsys, "ibmebus") == 0) || (subsys == NULL)) {
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
grandparent = udev_device_get_parent(parent);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
if (grandparent)
udev: drop libgudev in favor of libudev libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
2017-03-12 15:54:02 +01:00
driver = udev_device_get_driver(grandparent);
platform: move code udev_get_driver() to nmp_utils_udev_get_driver()
2015-05-02 07:59:59 +02:00
}
}
}
out:
/* Intern the string so we don't have to worry about memory
* management in NMPlatformLink. */
return g_intern_string(driver);
}
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
/******************************************************************************
* utils
*****************************************************************************/
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
NMIPConfigSource
nmp_utils_ip_config_source_from_rtprot(guint8 rtprot)
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
{
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
return ((int) rtprot) + 1;
}
NMIPConfigSource
nmp_utils_ip_config_source_round_trip_rtprot(NMIPConfigSource source)
{
/* when adding a route to kernel for a give @source, the resulting route
* will be put into the cache with a source of NM_IP_CONFIG_SOURCE_RTPROT_*.
* This function returns that. */
return nmp_utils_ip_config_source_from_rtprot(
nmp_utils_ip_config_source_coerce_to_rtprot(source));
}
guint8
nmp_utils_ip_config_source_coerce_to_rtprot(NMIPConfigSource source)
{
/* when adding a route to kernel, we coerce the @source field
* to rtm_protocol. This is not lossless as we map different
* source values to the same RTPROT uint8 value. */
if (source <= NM_IP_CONFIG_SOURCE_UNKNOWN)
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
return RTPROT_UNSPEC;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: declare nmp_utils_ip_config_source_*() functions as const
2016-05-16 13:16:49 +02:00
if (source <= _NM_IP_CONFIG_SOURCE_RTPROT_LAST)
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
return source - 1;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
switch (source) {
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
case NM_IP_CONFIG_SOURCE_KERNEL:
return RTPROT_KERNEL;
platform: add NM_IP_CONFIG_SOURCE_IP6LL source type We already have IP4LL and maybe should re-use that also for IPv6. However, when adding the prefix route for IPv6 link local addresses, we want to add it with protocol "kernel", unlike "user" for IPv4. There is no strong reason for this. I don't think the protocol matters much. But up to now kernel automatically adds this prefix route, so as we are going to change that and let NetworkManager add it, keep the protocol at "kernel".
2018-03-08 13:34:54 +01:00
case NM_IP_CONFIG_SOURCE_IP6LL:
return RTPROT_KERNEL;
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
case NM_IP_CONFIG_SOURCE_DHCP:
return RTPROT_DHCP;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
case NM_IP_CONFIG_SOURCE_NDISC:
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
return RTPROT_RA;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
default:
return RTPROT_STATIC;
}
}
NMIPConfigSource
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
nmp_utils_ip_config_source_coerce_from_rtprot(NMIPConfigSource source)
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
{
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
/* When we receive a route from kernel and put it into the platform cache,
* we preserve the protocol field by converting it to a NMIPConfigSource
* via nmp_utils_ip_config_source_from_rtprot().
*
* However, that is not the inverse of nmp_utils_ip_config_source_coerce_to_rtprot().
* Instead, to go back to the original value, you need another step:
* nmp_utils_ip_config_source_coerce_from_rtprot (nmp_utils_ip_config_source_from_rtprot (rtprot)).
*
* This might partly restore the original source value, but of course that
* is not really possible because nmp_utils_ip_config_source_coerce_to_rtprot()
* is not injective.
* */
switch (source) {
case NM_IP_CONFIG_SOURCE_RTPROT_UNSPEC:
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
return NM_IP_CONFIG_SOURCE_UNKNOWN;
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
case NM_IP_CONFIG_SOURCE_RTPROT_KERNEL:
case NM_IP_CONFIG_SOURCE_RTPROT_REDIRECT:
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
return NM_IP_CONFIG_SOURCE_KERNEL;
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
case NM_IP_CONFIG_SOURCE_RTPROT_RA:
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
return NM_IP_CONFIG_SOURCE_NDISC;
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
case NM_IP_CONFIG_SOURCE_RTPROT_DHCP:
platform: expose nmp_utils_ip_config_source_to/from_rtprot() Will be used also from the tests.
2016-04-10 12:01:51 +02:00
return NM_IP_CONFIG_SOURCE_DHCP;
default:
return NM_IP_CONFIG_SOURCE_USER;
}
}
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
const char *
nmp_utils_ip_config_source_to_string(NMIPConfigSource source, char *buf, gsize len)
{
const char *s = NULL;
nm_utils_to_string_buffer_init(&buf, &len);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
if (!len)
return buf;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
switch (source) {
case NM_IP_CONFIG_SOURCE_UNKNOWN:
s = "unknown";
break;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
case NM_IP_CONFIG_SOURCE_RTPROT_UNSPEC:
s = "rt-unspec";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_REDIRECT:
s = "rt-redirect";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_KERNEL:
s = "rt-kernel";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_BOOT:
s = "rt-boot";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_STATIC:
s = "rt-static";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_DHCP:
s = "rt-dhcp";
break;
case NM_IP_CONFIG_SOURCE_RTPROT_RA:
s = "rt-ra";
break;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
case NM_IP_CONFIG_SOURCE_KERNEL:
s = "kernel";
break;
case NM_IP_CONFIG_SOURCE_SHARED:
s = "shared";
break;
case NM_IP_CONFIG_SOURCE_IP4LL:
s = "ipv4ll";
platform: add NM_IP_CONFIG_SOURCE_IP6LL source type We already have IP4LL and maybe should re-use that also for IPv6. However, when adding the prefix route for IPv6 link local addresses, we want to add it with protocol "kernel", unlike "user" for IPv4. There is no strong reason for this. I don't think the protocol matters much. But up to now kernel automatically adds this prefix route, so as we are going to change that and let NetworkManager add it, keep the protocol at "kernel".
2018-03-08 13:34:54 +01:00
break;
case NM_IP_CONFIG_SOURCE_IP6LL:
s = "ipv6ll";
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
break;
case NM_IP_CONFIG_SOURCE_PPP:
s = "ppp";
break;
case NM_IP_CONFIG_SOURCE_WWAN:
s = "wwan";
break;
case NM_IP_CONFIG_SOURCE_VPN:
s = "vpn";
break;
case NM_IP_CONFIG_SOURCE_DHCP:
s = "dhcp";
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
break;
case NM_IP_CONFIG_SOURCE_NDISC:
s = "ndisc";
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
break;
case NM_IP_CONFIG_SOURCE_USER:
s = "user";
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
break;
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
default:
break;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
platform: extend NMIPConfigSource to preserve the rtm_protocol field For addresses (NMPlatformIPAddress) the @addr_source field is ignored on a platform level. That is, all addresses inside the platform cache have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason, the source should not be a part of the NMPlatformIPAddress structure, but it is convenient for users to piggy back the source inside the platform address structure. For routes, the source is stored in NMPlatformIPRoute's @rt_source field. When adding a route to kernel, we set the @rtm_protocol of the route depending on the source. However, we want to map different source values to the same protocol value. On the other hand, when kernel sends us a route that gets put inside the cache, we must preserve the protocol value and must not map different protocol values to the same source. The reason is, that a user can add two routes that only differ by @rtm_protocol. In that sense, the @rtm_protocol fields is part of the unique ID of a kernel route, and thus different values must map to different sources. Fix this, by extending the range of NMIPConfigSource to contain a range of protocol fields.
2016-04-11 17:35:29 +02:00
if (source >= 1 && source <= 0x100) {
if (s)
g_snprintf(buf, len, "%s", s);
else
g_snprintf(buf, len, "rt-%d", ((int) source) - 1);
} else {
if (s)
g_strlcpy(buf, s, len);
else
g_snprintf(buf, len, "(%d)", source);
}
return buf;
}
platform: add nmp_utils_ip_config_source_to_string() Expose nmp_utils_ip_config_source_to_string() in the header file and implement it via NM_UTILS_ENUM2STR_DEFINE().
2016-04-11 14:29:17 +02:00
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
/**
* nmp_utils_sysctl_open_netdir:
* @ifindex: the ifindex for which to open "/sys/class/net/%s"
* @ifname_guess: (allow-none): optional argument, if present used as initial
* guess as the current name for @ifindex. If guessed right,
docs: misc. typos Found via `codespell -q 3 --skip="*.po"` https://github.com/NetworkManager/NetworkManager/pull/203
2018-09-14 23:49:20 -04:00
* it saves an additional if_indextoname() call.
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
* @out_ifname: (allow-none): if present, must be at least IFNAMSIZ
* characters. On success, this will contain the actual ifname
* found while opening the directory.
*
* Returns: a negative value on failure, on success returns the open fd
* to the "/sys/class/net/%s" directory for @ifindex.
*/
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
int
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
nmp_utils_sysctl_open_netdir(int ifindex, const char *ifname_guess, char *out_ifname)
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
{
#define SYS_CLASS_NET "/sys/class/net/"
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
const char *ifname = ifname_guess;
char ifname_buf_last_try[IFNAMSIZ];
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
char ifname_buf[IFNAMSIZ];
guint try_count = 0;
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
char sysdir[NM_STRLEN(SYS_CLASS_NET) + IFNAMSIZ] = SYS_CLASS_NET;
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
char fd_buf[256];
ssize_t nn;
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
g_return_val_if_fail(ifindex >= 0, -1);
ifname_buf_last_try[0] = '\0';
for (try_count = 0; try_count < 10; try_count++, ifname = NULL) {
nm_auto_close int fd_dir = -1;
nm_auto_close int fd_ifindex = -1;
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
if (!ifname) {
platform: use wrappers for if_nametoindex() and if_indextoname()
2016-12-26 12:00:08 +01:00
ifname = nmp_utils_if_indextoname(ifindex, ifname_buf);
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
if (!ifname)
return -1;
}
all: use nm_utils_ifname_valid_kernel() instead of nm_utils_is_valid_iface_name() nm_utils_is_valid_iface_name() is a public API of libnm-core, let's use our internal API. $ sed -i 's/\<nm_utils_is_valid_iface_name\>/nm_utils_ifname_valid_kernel/g' $(git grep -l nm_utils_is_valid_iface_name)
2020-02-12 18:01:13 +01:00
nm_assert(nm_utils_ifname_valid_kernel(ifname, NULL));
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
if (g_strlcpy(&sysdir[NM_STRLEN(SYS_CLASS_NET)], ifname, IFNAMSIZ) >= IFNAMSIZ)
g_return_val_if_reached(-1);
/* we only retry, if the name changed since previous attempt.
* Hence, it is extremely unlikely that this loop runes until the
* end of the @try_count. */
if (nm_streq(ifname, ifname_buf_last_try))
return -1;
strcpy(ifname_buf_last_try, ifname);
fd_dir = open(sysdir, O_DIRECTORY | O_CLOEXEC);
if (fd_dir < 0)
continue;
fd_ifindex = openat(fd_dir, "ifindex", O_CLOEXEC);
if (fd_ifindex < 0)
continue;
nn = nm_utils_fd_read_loop(fd_ifindex, fd_buf, sizeof(fd_buf) - 2, FALSE);
if (nn <= 0)
continue;
fd_buf[nn] = '\0';
platform: use nm_steal_fd() in nmp_utils_sysctl_open_netdir()
2018-12-23 11:28:42 +01:00
if (ifindex != (int) _nm_utils_ascii_str_to_int64(fd_buf, 10, 1, G_MAXINT, -1))
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
continue;
if (out_ifname)
strcpy(out_ifname, ifname);
platform: use nm_steal_fd() in nmp_utils_sysctl_open_netdir()
2018-12-23 11:28:42 +01:00
return nm_steal_fd(&fd_dir);
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
}
platform: refactor nmp_utils_sysctl_open_netdir() - use nm_auto_close cleanup attribute - optionally, return the found ifname - don't stat "phy80211". If such an entity can be opened, just assume it's a directory.
2016-12-08 13:55:17 +01:00
platform: add a new function nmp_utils_open_sysctl() A race condition may happen when NetworkManager opens sysfs and udev renames interface name at the same time. Thomas Haller provides a new function [1] which can avoid the race condition when opening sysfs. This patch is a direct copy from [1]. [1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2016-12-07 18:15:13 +08:00
return -1;
}
Reference in a new issue Copy permalink