All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Srujana Challa <schalla@marvell.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [EXTERNAL] [PATCH 6.12.y] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN
Date: Wed, 8 Apr 2026 10:34:52 -0400	[thread overview]
Message-ID: <20260408103355-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <adZitVex9UGVyH-V@laps>

On Wed, Apr 08, 2026 at 10:14:13AM -0400, Sasha Levin wrote:
> On Wed, Apr 08, 2026 at 01:49:48PM +0000, Srujana Challa wrote:
> > > From: Srujana Challa <schalla@marvell.com>
> > > 
> > > [ Upstream commit b4e5f04c58a29c499faa85d12952ca9a4faf1cb9 ]
> > > 
> > > rss_max_key_size in the virtio spec is the maximum key size supported by the
> > > device, not a mandatory size the driver must use. Also the value 40 is a spec
> > > minimum, not a spec maximum.
> > > 
> > > The current code rejects RSS and can fail probe when the device reports a
> > > larger rss_max_key_size than the driver buffer limit. Instead, clamp the
> > > effective key length to min(device rss_max_key_size, NETDEV_RSS_KEY_LEN)
> > > and keep RSS enabled.
> > > 
> > > This keeps probe working on devices that advertise larger maximum key sizes
> > > while respecting the netdev RSS key buffer size limit.
> > > 
> > > Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Srujana Challa <schalla@marvell.com>
> > > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > > Link: https://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__patch.msgid.link_20260326142344.1171317-2D1-2Dschalla-
> > > 40marvell.com&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Fj4OoD5hcKFp
> > > ANhTWdwQzjT1Jpf7veC5263T47JVpnc&m=0XuKVXgk9_1LUIZHeqL0znGhAh
> > > x5KvAOLvrCl-orVeQSt__4o6Djr-79rwCl6KNp&s=cfQpAcZTTE7nTYku-
> > > MVkfip0xUJoBBw4ikqm9iEdgcc&e=
> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ changed clamp target from
> > > NETDEV_RSS_KEY_LEN to VIRTIO_NET_RSS_MAX_KEY_SIZE ]
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > ---
> > >  drivers/net/virtio_net.c | 16 ++++++++--------
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > > 5c83983f0eb3f..5a31ccdae2e22 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -6502,6 +6502,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > >  	struct virtnet_info *vi;
> > >  	u16 max_queue_pairs;
> > >  	int mtu = 0;
> > > +	u16 key_sz;
> > > 
> > >  	/* Find if host supports multiqueue/rss virtio_net device */
> > >  	max_queue_pairs = 1;
> > > @@ -6624,14 +6625,13 @@ static int virtnet_probe(struct virtio_device
> > > *vdev)
> > >  		goto free;
> > > 
> > >  	if (vi->has_rss || vi->has_rss_hash_report) {
> > > -		vi->rss_key_size =
> > > -			virtio_cread8(vdev, offsetof(struct virtio_net_config,
> > > rss_max_key_size));
> > > -		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;
> > > -		}
> > > +		key_sz = virtio_cread8(vdev, offsetof(struct virtio_net_config,
> > > +rss_max_key_size));
> > > +
> > > +		vi->rss_key_size = min_t(u16, key_sz,
> > > VIRTIO_NET_RSS_MAX_KEY_SIZE);
> > > +		if (key_sz > vi->rss_key_size)
> > > +			dev_warn(&vdev->dev,
> > > +				 "rss_max_key_size=%u exceeds driver limit
> > > %u, clamping\n",
> > > +				 key_sz, vi->rss_key_size);
> > > 
> > >  		vi->rss_hash_types_supported =
> > >  		    virtio_cread32(vdev, offsetof(struct virtio_net_config,
> > > supported_hash_types));
> > > --
> > > 2.53.0
> > 
> > We used `NETDEV_RSS_KEY_LEN` intentionally for clamping.
> > `rss_max_key_size` is the maximum supported by the device,
> > while `40` is a spec minimum, not a maximum.
> > Clamping to `VIRTIO_NET_RSS_MAX_KEY_SIZE` would unnecessarily
> > limit valid devices(for example devices advertising 48/52 bytes) and
> > could reintroduce the original issue.
> > 
> > Could you please share the reason for changing the clamp target
> > from `NETDEV_RSS_KEY_LEN` to `VIRTIO_NET_RSS_MAX_KEY_SIZE`?
> 
> Hi Srujana,
> 
> In the upstream commit, the key buffer was also enlarged from 40 to 52 bytes as
> part of the `TRAILING_OVERLAP` / `rss_trailer` refactoring:
> 
> -		u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
> +		u8 rss_hash_key_data[NETDEV_RSS_KEY_LEN];
> 
> That refactoring isn't present in 6.12, so the key buffer is still `u8
> key[VIRTIO_NET_RSS_MAX_KEY_SIZE]` (40 bytes). Clamping to `NETDEV_RSS_KEY_LEN`
> (52) here would allow writing up to 52 bytes into a 40-byte buffer, so the
> clamp target had to match the actual buffer size in this tree.
> 
> -- 
> Thanks,
> Sasha


problem is, the commit log now says one thing and the patch does
a completely different, and in fact opposite, thing.


Why not pick that dependency then?

-- 
MST


  reply	other threads:[~2026-04-08 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08  6:59 FAILED: patch "[PATCH] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN" failed to apply to 6.12-stable tree gregkh
2026-04-08 13:19 ` [PATCH 6.12.y] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN Sasha Levin
2026-04-08 13:49   ` [EXTERNAL] " Srujana Challa
2026-04-08 14:14     ` Sasha Levin
2026-04-08 14:34       ` Michael S. Tsirkin [this message]
2026-04-08 14:48     ` Michael S. Tsirkin
2026-04-08 14:56       ` Sasha Levin
2026-04-08 17:01         ` Srujana Challa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260408103355-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=kuba@kernel.org \
    --cc=sashal@kernel.org \
    --cc=schalla@marvell.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.