[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Apr 2021 11:14:31 +0300
From: Danielle Ratson <danieller@...dia.com>
To: <netdev@...r.kernel.org>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <eric.dumazet@...il.com>,
<andrew@...n.ch>, <mkubecek@...e.cz>, <f.fainelli@...il.com>,
<acardace@...hat.com>, <irusskikh@...vell.com>,
<gustavo@...eddedor.com>, <magnus.karlsson@...el.com>,
<ecree@...arflare.com>, <idosch@...dia.com>, <jiri@...dia.com>,
<mlxsw@...dia.com>, Danielle Ratson <danieller@...dia.com>
Subject: [PATCH net v2 0/2] Fix link_mode derived params functionality
Currently, link_mode parameter derives 3 other link parameters, speed,
lanes and duplex, and the derived information is sent to user space.
Two bugs were found in that functionality.
First, some drivers clear the 'ethtool_link_ksettings' struct in their
get_link_ksettings() callback and cause receiving wrong link mode
information in user space. And also, some drivers can report random
values in the 'link_mode' field and cause general protection fault.
Second, the link parameters are only derived in netlink path so in ioctl
path, we don't any reasonable values.
Patch #1 solves the first problem by introducing a new capability bit for
supporting link_mode in driver.
Patch #2 solves the second one, by deriving the parameters in ioctl path
as well.
v2:
* Add patch #2.
* Introduce 'cap_link_mode_supported' instead of adding a
validity field to 'ethtool_link_ksettings' struct in patch #1.
Danielle Ratson (2):
ethtool: Add link_mode parameter capability bit to ethtool_ops
ethtool: Derive parameters from link_mode in ioctl path
.../mellanox/mlxsw/spectrum_ethtool.c | 1 +
include/linux/ethtool.h | 5 ++-
net/ethtool/ioctl.c | 34 ++++++++++++++-----
3 files changed, 31 insertions(+), 9 deletions(-)
--
2.26.2
Powered by blists - more mailing lists