kernel/linux.git/net/ethtool/common.h, branch v7.2-rc1

net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()

2026-06-25T17:18:34+00:00

Breno reports following splats on mlx5: RTNL: assertion failed at net/core/dev.c (2241) WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335 RIP: 0010:netif_state_change+0xf9/0x130 Call Trace: __linkwatch_sync_dev+0xea/0x120 ethtool_op_get_link+0xe/0x20 __ethtool_get_link+0x26/0x40 linkstate_prepare_data+0x51/0x200 ethnl_default_doit+0x213/0x470 genl_family_rcv_msg_doit+0xdd/0x110 Looks like I missed ethtool_op_get_link() trying to sync linkwatch, which needs rtnl_lock. Not all drivers do this - bnxt doesn't, it just returns the link state, so add an opt-in bit. Reported-by: Breno Leitao Fixes: 45079e00133e ("net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops") Acked-by: Stanislav Fomichev Reviewed-by: Breno Leitao Acked-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260624190439.2521219-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: tsconfig: always take rtnl_lock

2026-06-12T23:41:56+00:00

mlx5 throws ASSERT_RTNL() warnings on timestamp config, because it tries to update features. mlx5e_hwtstamp_set() calls netdev_update_features(). I missed this while grepping the drivers because tsconfig goes through ndo_hwtstamp_set/get, not ethtool ops, even tho the new uAPI is in ethtool Netlink. We could add a dedicated opt out bit for mlx5, but NDOs were not supposed to be part of the ethtool locking conversion in the first place. The mlx5 features update is related to the "compressed CQE" format which lacks timestamp, apparently. See commit c0194e2d0ef0 ("net/mlx5e: Disable rxhash when CQE compress is enabled"). Fixes: f9a3e05114b8 ("net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops") Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Reviewed-by: Vadim Fedorenko Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260611200355.2020663-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

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: add get_rx_ring_count callback to optimize RX ring queries

2025-09-18T14:07:37+00:00

Add a new optional get_rx_ring_count callback in ethtool_ops to allow drivers to provide the number of RX rings directly without going through the full get_rxnfc flow classification interface. Create ethtool_get_rx_ring_count() to use .get_rx_ring_count if available, falling back to get_rxnfc() otherwise. It needs to be non-static, given it will be called by other ethtool functions laters, as those calling get_rxfh(). Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20250917-gxrings-v4-4-dae520e2e1cb@debian.org Signed-off-by: Jakub Kicinski

ethtool: move ethtool_rxfh_ctx_alloc() to common code

2025-07-22T01:20:19+00:00

Move ethtool_rxfh_ctx_alloc() to common code, Netlink will need it. Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20250717234343.2328602-6-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: rejig the RSS notification machinery for more types

2025-07-22T01:20:19+00:00

In anticipation for CREATE and DELETE notifications - explicitly pass the notification type to ethtool_rss_notify(), when calling from the IOCTL code. Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20250717234343.2328602-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: rss: support setting input-xfrm via Netlink

2025-07-17T23:13:59+00:00

Support configuring symmetric hashing via Netlink. We have the flow field config prepared as part of SET handling, so scan it for conflicts instead of querying the driver again. Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20250716000331.1378807-10-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ethtool: rss: add notifications

2025-06-25T22:24:14+00:00

In preparation for RSS_SET handling in ethnl introduce Netlink notifications for RSS. Only cover modifications, not creation and not removal of a context, because the latter may deserve a different notification type. We should cross that bridge when we add the support for context add / remove via Netlink. Link: https://patch.msgid.link/20250623231720.3124717-7-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ethtool: Export the link_mode_params definitions

2025-03-18T08:03:11+00:00

link_mode_params contains a lookup table of all 802.3 link modes that are currently supported with structured data about each mode's speed, duplex, number of lanes and mediums. As a preparation for a port representation, export that table for the rest of the net stack to use. Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20250307173611.129125-2-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni