From: "Michael S. Tsirkin" <mst@redhat.com>
To: Srujana Challa <schalla@marvell.com>
Cc: Sasha Levin <sashal@kernel.org>,
"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:48:57 -0400 [thread overview]
Message-ID: <20260408104825-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CH3PR18MB6379BBB26D572A68D09D8CB1A05BA@CH3PR18MB6379.namprd18.prod.outlook.com>
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`?
>
> Thanks!
Srujana,
do you want to do the stable backport yourself?
--
MST
next prev parent reply other threads:[~2026-04-08 14:49 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
2026-04-08 14:48 ` Michael S. Tsirkin [this message]
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=20260408104825-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox