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: <20260122050904-mutt-send-email-mst@kernel.org>
Date: Thu, 22 Jan 2026 05:15:43 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Srujana Challa <schalla@...vell.com>
Cc: netdev@...r.kernel.org, virtualization@...ts.linux.dev,
	pabeni@...hat.com, jasowang@...hat.com, xuanzhuo@...ux.alibaba.com,
	eperezma@...hat.com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, ndabilpuram@...vell.com
Subject: Re: [PATCH net-next] virtio_net: Increase RSS max key size to match
 NETDEV_RSS_KEY_LEN

On Thu, Jan 22, 2026 at 02:45:27PM +0530, Srujana Challa wrote:
> Increase VIRTIO_NET_RSS_MAX_KEY_SIZE from 40 to 52 bytes to align with
> the kernel's standard RSS key length defined by NETDEV_RSS_KEY_LEN.
> 
> The virtio specification requires devices to support at least 40 bytes
> for the RSS key size.

Indeed:
	The device MUST set \field{rss_max_key_size} to at least 40, if it offers
	VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT.



> However, devices may support larger key sizes
> up to 52 bytes (as reported by the device's rss_max_key_size config
> field). This change allows such devices to work properly.
> Previously, devices reporting rss_max_key_size > 40 would fail with
> an error during initialization.

This one, yes?

                if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
                        dev_err(&vdev->dev, "rss_max_key_size=%u exceeds the limit %u.\n",
                                vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE);
                        err = -EINVAL;
                        goto free;
                }


Hmm but why do we do it like this? I suspect we just got confused with
the spec: > vs <.


Can't we just do:
min(vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE)


If yes I'd like that fix in addition to the increase.



If we are validating rss_key_size  against 40, I think we should clear the
feature rather than failing init completely.






> The driver already handles variable key sizes dynamically through
> vi->rss_key_size, so increasing the maximum limit is safe and
> maintains backward compatibility with devices that support smaller
> key sizes.
> 
> Signed-off-by: Srujana Challa <schalla@...vell.com>
> ---
>  drivers/net/virtio_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index db88dcaefb20..5f06cbc058d7 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -381,7 +381,7 @@ struct receive_queue {
>  	struct xdp_buff **xsk_buffs;
>  };
>  
> -#define VIRTIO_NET_RSS_MAX_KEY_SIZE     40
> +#define VIRTIO_NET_RSS_MAX_KEY_SIZE     52
>  
>  /* Control VQ buffers: protected by the rtnl lock */
>  struct control_buf {
> -- 
> 2.25.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ