netdev - Re: [PATCH net-next v2 06/12] ethtool: rss: don't report key if device doesn't support it

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: <2af37636-de5d-913d-4ccf-9388f1cfbd26@gmail.com>
Date: Mon, 5 Aug 2024 15:36:28 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Cc: netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 dxu@...uu.xyz, przemyslaw.kitszel@...el.com, donald.hunter@...il.com,
 gal.pressman@...ux.dev, tariqt@...dia.com, willemdebruijn.kernel@...il.com,
 jdamato@...tly.com
Subject: Re: [PATCH net-next v2 06/12] ethtool: rss: don't report key if
 device doesn't support it

On 03/08/2024 05:26, Jakub Kicinski wrote:
> marvell/otx2 and mvpp2 do not support setting different
> keys for different RSS contexts. Contexts have separate
> indirection tables but key is shared with all other contexts.
> This is likely fine, indirection table is the most important
> piece.

Since drivers that do not support this are the odd ones out,
 would it be better to invert the sense of the flag?  Or is
 this to make sure that driver authors who don't think/know
 about the distinction automatically get safe behaviour?

> Don't report the key-related parameters from such drivers.
> This prevents driver-errors, e.g. otx2 always writes
> the main key, even when user asks to change per-context key.
> The second reason is that without this change tracking
> the keys by the core gets complicated. Even if the driver
> correctly reject setting key with rss_context != 0,
> change of the main key would have to be reflected in
> the XArray for all additional contexts.
> 
> Since the additional contexts don't have their own keys
> not including the attributes (in Netlink speak) seems
> intuitive. ethtool CLI seems to deal with it just fine.
> 
> Reviewed-by: Joe Damato <jdamato@...tly.com>
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
...
> diff --git a/drivers/net/ethernet/sfc/ef100_ethtool.c b/drivers/net/ethernet/sfc/ef100_ethtool.c
> index 746b5314acb5..127b9d6ade6f 100644
> --- a/drivers/net/ethernet/sfc/ef100_ethtool.c
> +++ b/drivers/net/ethernet/sfc/ef100_ethtool.c
> @@ -58,6 +58,7 @@ const struct ethtool_ops ef100_ethtool_ops = {
>  
>  	.get_rxfh_indir_size	= efx_ethtool_get_rxfh_indir_size,
>  	.get_rxfh_key_size	= efx_ethtool_get_rxfh_key_size,
> +	.rxfh_per_ctx_key	= 1,

I would prefer 'true' for the sfc drivers, I think that
 better fits the general style of our code.

>  	.rxfh_priv_size		= sizeof(struct efx_rss_context_priv),
>  	.get_rxfh		= efx_ethtool_get_rxfh,
>  	.set_rxfh		= efx_ethtool_set_rxfh,
> diff --git a/drivers/net/ethernet/sfc/ethtool.c b/drivers/net/ethernet/sfc/ethtool.c
> index 15245720c949..e4d86123b797 100644
> --- a/drivers/net/ethernet/sfc/ethtool.c
> +++ b/drivers/net/ethernet/sfc/ethtool.c
> @@ -267,6 +267,7 @@ const struct ethtool_ops efx_ethtool_ops = {
>  	.set_rxnfc		= efx_ethtool_set_rxnfc,
>  	.get_rxfh_indir_size	= efx_ethtool_get_rxfh_indir_size,
>  	.get_rxfh_key_size	= efx_ethtool_get_rxfh_key_size,
> +	.rxfh_per_ctx_key	= 1,
>  	.rxfh_priv_size		= sizeof(struct efx_rss_context_priv),
>  	.get_rxfh		= efx_ethtool_get_rxfh,
>  	.set_rxfh		= efx_ethtool_set_rxfh,
> diff --git a/drivers/net/ethernet/sfc/siena/ethtool.c b/drivers/net/ethernet/sfc/siena/ethtool.c
> index 4c182d4edfc2..6d4e5101433a 100644
> --- a/drivers/net/ethernet/sfc/siena/ethtool.c
> +++ b/drivers/net/ethernet/sfc/siena/ethtool.c
> @@ -241,6 +241,7 @@ static int efx_ethtool_get_ts_info(struct net_device *net_dev,
>  
>  const struct ethtool_ops efx_siena_ethtool_ops = {
>  	.cap_rss_ctx_supported	= true,
> +	.rxfh_per_ctx_key	= true,

For the record, Siena hardware doesn't actually support
 custom RSS contexts; the code is only present in the
 driver as a holdover from when Siena and EF10 used the
 same driver.  Trying to actually use them on Siena will
 fail -EOPNOTSUPP.[1]
I'll send a patch to rip it out.

>  	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
>  				     ETHTOOL_COALESCE_USECS_IRQ |
>  				     ETHTOOL_COALESCE_USE_ADAPTIVE_RX,
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 55c9f613ab64..16f72a556fe9 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -731,6 +731,8 @@ struct kernel_ethtool_ts_info {
>   *	do not have to set this bit.
>   * @cap_rss_sym_xor_supported: indicates if the driver supports symmetric-xor
>   *	RSS.
> + * @rxfh_per_ctx_key: device supports setting different RSS key for each
> + *	additional context.

This comment should really make clear that it covers hfunc and
 input_xfrm as well, not just the key itself.

-ed

[1]: https://elixir.bootlin.com/linux/v6.10.3/source/drivers/net/ethernet/sfc/siena/ethtool_common.c#L1234