linux.git/net/ethtool/netlink.c, branch v7.2-rc2

net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops

2026-06-09T17:13:05+00:00

Make ethtool not take rtnl_lock for SET commands when operation
is performed on an ops-locked driver. cfg/cfg_pending are now
ops-locked, since only ethtool modifies them.

Some SET driver callbacks will still need rtnl_lock, most notably
those which may end up calling netdev_update_features() or the qdisc
layer (via netif_set_real_num_tx_queues()). Let drivers selectively
opt back into the rtnl_lock with a new bitfield in ops.

We need two helpers since Netlink and ioctl cmds have different
values. Keep the helpers side by side in common.h to make sure
they get updated together, even tho they will only get called
from ioctl.c and netlink.c.

SET commands which don't use ethnl_default_set_doit() are converted
by subsequent commits.

Reviewed-by: Eric Dumazet 
Acked-by: Stanislav Fomichev 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/20260605002912.3456868-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops

2026-06-09T17:13:04+00:00

ethnl_default_doit() and ethnl_default_dump_one() are both used
exclusively for GET callbacks (former to get info for a single
device or get global strings). ops-locked devices don't need
rtnl_lock for GET callbacks, stop taking it.

Introduce an opt-out mechanism for devices which use phylink (fbnic)
since phylink currently depends on rtnl_lock protection. Subsequent
patches will add more exceptions, anyway. Practically the new helpers
for judging if command needs rtnl_lock could also call
netdev_need_ops_lock() but I find that it makes the code in the callers
slightly less obvious.

Add a helper for IOCTLs already, even tho it's unused so that
we can keep them in sync as the series progresses.

This is the first user-visible step of moving ethtool ops out
from under rtnl. Subsequent patches do the same for SET ops,
as well as the ioctl path.

Reviewed-by: Eric Dumazet 
Acked-by: Stanislav Fomichev 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/20260605002912.3456868-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ethtool: relax ethnl_req_get_phydev() locking assertion

2026-06-09T17:13:04+00:00

phydev <> netdev linking and lifecycle depends on rtnl_lock.
We want to switch to instance locks for most ethtool ops.
Let's add an assert that ops locked devices don't use phydev
today. If one does we can either opt the phy ops out of
being purely ops locked, or do deeper surgery to make phy
locking ops-compatible. I don't think there's any fundamental
challenge to make that work.

Reviewed-by: Nicolai Buchwitz 
Reviewed-by: Maxime Chevallier 
Reviewed-by: Eric Dumazet 
Acked-by: Stanislav Fomichev 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/20260605002912.3456868-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ethtool: serialize broadcast notification sequence allocation

2026-06-09T17:13:04+00:00

ethnl_bcast_seq is a global counter stamped into the nlmsg_seq field
of every multicast notification, allowing userspace to detect dropped
messages. Today the ordering is achieved by using rtnl_lock().

Moving forward we will want ethtool ops to run under just the netdev
instance lock so to establish ordering we need a separate lock
for notifications. With the netdev instance locks operations on
different devices may bypass each other but the expectation is
that it should not matter. What we need to prevent is:
 - notification IDs getting out of order
 - operations on one device getting out of order

For simplicity defer allocating the ID of the notification right
before the notification is delivered. This removes the need for
special handling in ethnl_rss_create_send_ntf().

Reviewed-by: Eric Dumazet 
Acked-by: Stanislav Fomichev 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/20260605002912.3456868-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: rename netdev_ops_assert_locked()

2026-06-04T21:04:55+00:00

Jakub suggests renaming the existing assert to match
the netdev_lock_ops_compat() semantics.

We want netdev_assert_locked_ops() to mean - if the driver
is ops locked - check that it's holding the device lock.

The existing helper check for either ops lock or rtnl_lock,
which is the locking behavior of netdev_lock_ops_compat().

The reason for naming divergence is likely that
netdev_ops_assert_locked() predated the _compat() helpers.

Suggested-by: Jakub Sitnicki 
Reviewed-by: Nicolai Buchwitz 
Reviewed-by: Jakub Sitnicki 
Acked-by: Stanislav Fomichev 
Link: https://patch.msgid.link/20260603012840.2254293-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ethtool: don't take rtnl_lock for global string dump

2026-05-28T21:46:10+00:00

ETHTOOL_MSG_STRSET_GET is the only op which sets allow_nodev_do.
When no device is provided it dumps static tables, there's no
need to hold rtnl_lock for this.

Not taking rtnl_lock is a minor win in itself so I think this
patch stands on its own merits. Later on it will be useful
to do locking only in paths which have access to a netdev,
so that we can decide which locks to take per-netdev.

Reviewed-by: Vadim Fedorenko 
Link: https://patch.msgid.link/20260527162522.3344231-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski

ethtool: module: fix cleanup if socket used for flashing multiple devices

2026-05-26T15:19:32+00:00

When a single Netlink socket issues MODULE_FW_FLASH_ACT against multiple
devices, ethnl_sock_priv_set() overwrites sk_priv->dev on each call,
retaining only the last one. The socket priv is used on socket close,
to walk the global work list and mark the uncompleted flashing work
as "orphaned". Otherwise if another socket reuses the PID it will
unexpectedly receive the flashing notifications.

Don't record the device, record net pointer instead. The purpose of
the dev is to scope the work to a netns, anyway. If we store netns
the overrides are safe/a nop since all flashed devices must be in
the same netns as the socket.

Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware")
Reviewed-by: Danielle Ratson 
Link: https://patch.msgid.link/20260522231312.1710836-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ethtool: pass genl_info to the ethnl parse_request operation

2026-03-25T03:14:29+00:00

The .parse_request() ethnl operation extracts the relevant attributes
from the netlink request to populate the private req_info.

By passing genl_info as a parameter to this callback, we can use
the GENL_REQ_ATTR_CHECK() macro to check for missing mandatory
parameters.

This macro has the advantage of returning a better error explanation
through the netlink_ext_ack struct.

Convert the eeprom ethnl code to this macro, as it's the only command
yet that has mandatory request parameters.

Suggested-by: Jakub Kicinski 
Signed-off-by: Maxime Chevallier 
Link: https://patch.msgid.link/20260323095833.136266-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski

net: ethtool: re-order local includes

2026-03-21T02:10:18+00:00

Most local #include in the ethtool command handling is out of order,
with either :

 #include "netlink.h"
 #include "common.h"

or even :

 #include "netlink.h"
 #include "common.h"
 #include "bitset.h"

One of the reasons is because bitset.h s lacking definitions for
nlattr, netlink_ext_ack, ETH_GSTRING_LEN, and types such as u32, bool,
etc.

Make bitset.h standalone by including  for
ETH_GSTRING_LEN, and  for nlattr, netlink_ext_ack and
the rest.

While at it, take a pass on ethnl sources to re-order the local
includes :
 - put them after the global includes
 - add a newline between global and local includes
 - alpha-sort the local includes

One notable exception is the cmis.h include, that needs definitions from
module_fw.h. Keep them in this order for now.

Signed-off-by: Maxime Chevallier 
Link: https://patch.msgid.link/20260319180555.1531386-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski

ethtool: netlink: add ETHTOOL_MSG_MSE_GET and wire up PHY MSE access

2025-11-04T02:32:27+00:00

Introduce the userspace entry point for PHY MSE diagnostics via
ethtool netlink. This exposes the core API added previously and
returns both capability information and one or more snapshots.

Userspace sends ETHTOOL_MSG_MSE_GET. The reply carries:
- ETHTOOL_A_MSE_CAPABILITIES: scale limits and timing information
- ETHTOOL_A_MSE_CHANNEL_* nests: one or more snapshots (per-channel
  if available, otherwise WORST, otherwise LINK)

Link down returns -ENETDOWN.

Changes:
  - YAML: add attribute sets (mse, mse-capabilities, mse-snapshot)
    and the mse-get operation
  - UAPI (generated): add ETHTOOL_A_MSE_* enums and message IDs,
    ETHTOOL_MSG_MSE_GET/REPLY
  - ethtool core: add net/ethtool/mse.c implementing the request,
    register genl op, and hook into ethnl dispatch
  - docs: document MSE_GET in ethtool-netlink.rst

The include/uapi/linux/ethtool_netlink_generated.h is generated
from Documentation/netlink/specs/ethtool.yaml.

Signed-off-by: Oleksij Rempel 
Link: https://patch.msgid.link/20251027122801.982364-3-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski