netdev - Re: [PATCH net-next 05/11] ethtool: rss: support setting hfunc via Netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5686fbfb-4e47-48fd-93f9-25443aeb1d89@nvidia.com>
Date: Sun, 13 Jul 2025 14:10:20 +0300
From: Gal Pressman <gal@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Cc: netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 andrew+netdev@...n.ch, horms@...nel.org, donald.hunter@...il.com,
 shuah@...nel.org, kory.maincent@...tlin.com, maxime.chevallier@...tlin.com,
 sdf@...ichev.me, ecree.xilinx@...il.com
Subject: Re: [PATCH net-next 05/11] ethtool: rss: support setting hfunc via
 Netlink

On 11/07/2025 4:52, Jakub Kicinski wrote:
> Support setting RSS hash function / algo via ethtool Netlink.
> Like IOCTL we don't validate that the function is within the
> range known to the kernel. The drivers do a pretty good job
> validating the inputs, and the IDs are technically "dynamically
> queried" rather than part of uAPI.
> 
> Only change should be that in Netlink we don't support user
> explicitly passing ETH_RSS_HASH_NO_CHANGE (0), if no change
> is requested the attribute should be absent.

Makes sense.

> @@ -487,6 +488,9 @@ ethnl_rss_set_validate(struct ethnl_req_info *req_info, struct genl_info *info)
>  	if (request->rss_context && !ops->create_rxfh_context)
>  		bad_attr = bad_attr ?: tb[ETHTOOL_A_RSS_CONTEXT];
>  
> +	if (request->rss_context && !ops->rxfh_per_ctx_key)
> +		bad_attr = bad_attr ?: tb[ETHTOOL_A_RSS_HFUNC];

Clever, I expected an 'if (tb[ETHTOOL_A_RSS_HFUNC])'.

> +
>  	if (bad_attr) {
>  		NL_SET_BAD_ATTR(info->extack, bad_attr);
>  		return -EOPNOTSUPP;
> @@ -586,6 +590,8 @@ rss_set_ctx_update(struct ethtool_rxfh_context *ctx, struct nlattr **tb,
>  			ethtool_rxfh_context_indir(ctx)[i] = rxfh->indir[i];
>  		ctx->indir_configured = !!nla_len(tb[ETHTOOL_A_RSS_INDIR]);
>  	}
> +	if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE)
> +		ctx->hfunc = rxfh->hfunc;
>  }
>  
>  static int
> @@ -617,7 +623,11 @@ ethnl_rss_set(struct ethnl_req_info *req_info, struct genl_info *info)
>  		goto exit_clean_data;
>  	mod |= indir_mod;
>  
> -	rxfh.hfunc = ETH_RSS_HASH_NO_CHANGE;
> +	rxfh.hfunc = data.hfunc;

What is this for?

> +	ethnl_update_u8(&rxfh.hfunc, tb[ETHTOOL_A_RSS_HFUNC], &mod);
> +	if (rxfh.hfunc == data.hfunc)
> +		rxfh.hfunc = ETH_RSS_HASH_NO_CHANGE;

I think that this is a distinction that we don't currently make in the
drivers/ioctl flow.

NO_CHANGE was specifically used for cases where the user didn't specify
a parameter, not for cases where the request is equal to the configured one.
mlx5 for example, performs this check internally because it can't rely
on NO_CHANGE for requested == configured.

> +
>  	rxfh.input_xfrm = RXH_XFRM_NO_CHANGE;
>  
>  	mutex_lock(&dev->ethtool->rss_lock);