kernel/git/stable/linux-stable.git/net/ethtool/netlink.h, branch master

ethtool: rss: Fix hfunc and input_xfrm parsing on big endian

2026-07-09T09:38:30+00:00

ETHTOOL_A_RSS_HFUNC and ETHTOOL_A_RSS_INPUT_XFRM are NLA_U32 attributes, but ethnl_rss_set() and ethnl_rss_create_doit() parse them with ethnl_update_u8(), which reads a single byte. On little endian this happens to read the least significant byte and works as long as the value fits in a byte. On big endian it reads the most significant byte, so the requested value is parsed incorrectly. The destination fields in struct ethtool_rxfh_param are u8, so the attribute can't be read directly with ethnl_update_u32(). Cap the hfunc policy at U8_MAX so an out of range value is rejected instead of being silently truncated into the u8 field, and add ethnl_update_u8_u32() to read the full u32 and narrow it into the u8 destination. Fixes: 82ae67cbc423 ("ethtool: rss: support setting hfunc via Netlink") Fixes: d3e2c7bab124 ("ethtool: rss: support setting input-xfrm via Netlink") Fixes: a166ab7816c5 ("ethtool: rss: support creating contexts via Netlink") Reviewed-by: Dragos Tatulea Reviewed-by: Nimrod Oren Signed-off-by: Gal Pressman Link: https://patch.msgid.link/20260706055017.3355806-1-gal@nvidia.com Signed-off-by: Paolo Abeni

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: 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

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

ethtool: rss: support removing contexts via Netlink

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

Implement removing additional RSS contexts via Netlink. Technically it'd be possible to shoehorn the delete operation into ethnl_request_ops-compatible handler. The code ends up longer than open coded version, and I think we'll need a custom way of sending notifications at some stage (if we allow tying the context lifetime to the netlink socket, in the future). Link: https://patch.msgid.link/20250717234343.2328602-8-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: rss: support creating contexts via Netlink

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

Support creating contexts via Netlink. Setting flow hashing fields on the new context is not supported at this stage, it can be added later. An empty indirection table is not supported. This is a carry over from the IOCTL interface where empty indirection table meant delete. We can repurpose empty indirection table in Netlink but for now to avoid confusion reject it using the policy. Support letting user choose the ID for the new context. This was not possible in IOCTL since the context ID field for the create action had to be set to the ETH_RXFH_CONTEXT_ALLOC magic value. Link: https://patch.msgid.link/20250717234343.2328602-7-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: rss: support setting flow hashing fields

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

Add support for ETHTOOL_SRXFH (setting hashing fields) in RSS_SET. The tricky part is dealing with symmetric hashing. In netlink user can change the hashing fields and symmetric hash in one request, in IOCTL the two used to be set via different uAPI requests. Since fields and hash function config are still separate driver callbacks - changes to the two are not atomic. Keep things simple and validate the settings against both pre- and post- change ones. Meaning that we will reject the config request if user tries to correct the flow fields and set input_xfrm in one request, or disables input_xfrm and makes flow fields non-symmetric. We can adjust it later if there's a real need. Starting simple feels right, and potentially partially applying the settings isn't nice, either. Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20250716000331.1378807-11-kuba@kernel.org Signed-off-by: Jakub Kicinski