[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB47235781555A587B72107038D49C9@AM0PR04MB4723.eurprd04.prod.outlook.com>
Date: Mon, 17 Apr 2023 06:47:58 +0000
From: Alvaro Karsz <alvaro.karsz@...id-run.com>
To: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mst@...hat.com" <mst@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>
Subject: Re: [PATCH net] virtio-net: reject small vring sizes
> > Check vring size and fail probe if a transmit/receive vring size is
> > smaller than MAX_SKB_FRAGS + 2.
> >
> > At the moment, any vring size is accepted. This is problematic because
> > it may result in attempting to transmit a packet with more fragments
> > than there are descriptors in the ring.
>
> So, why we check the rx ring?
>
You're right, the rx check should be a little more complicated.
It depends on the negotiated features, like VIRTIO_NET_F_MTU, any guest GSO, VIRTIO_NET_F_MRG_RXBUF.
But MAX_SKB_FRAGS + 2 covers all the rx scenarios.
We may be able to accept smaller rx rings if for example none of the above features are negotiated.
If you think that this is necessary, we can do a more complex rx check.
Powered by blists - more mailing lists