Re: [RFC 1/2] virtio_net: timeout control virtqueue commands

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Oct 22, 2025 at 12:50:53PM +0200, Eugenio Perez Martin wrote:
> Let me switch to MQ as I think it illustrates the point better.
> 
> IIUC the workflow:
> a) virtio-net sends MQ_VQ_PAIRS_SET 2 to the device
> b) VDUSE CVQ sends ok to the virtio-net driver
> c) VDUSE CVQ sends the command to the VDUSE device
> d) Now the virtio-net driver sends virtio-net sends MQ_VQ_PAIRS_SET 1
> e) VDUSE CVQ sends ok to the virtio-net driver
> 
> The device didn't process the MQ_VQ_PAIRS_SET 1 command at this point,
> so it potentially uses the second rx queue. But, by the standard:
> 
> The device MUST NOT queue packets on receive queues greater than
> virtqueue_pairs once it has placed the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
> command in a used buffer.
> 
> So the driver does not expect rx buffers on that queue at all. From
> the driver's POV, the device is invalid, and it could mark it as
> broken.

ok intresting. Note that if userspace processes vqs it should process
cvq too. I don't know what to do in this case yet, I'm going on
vacation, let me ponder this a bit.


> And, what's worse, how to handle it if the device now replies with
> VIRTIO_NET_ERR to the VDUSE CVQ?

this part does not bother me much. break it, probably.

> > > If we wait for the device to reply, we're in the
> > > same situation regarding the RTNL.
> > >
> > > Now we receive a new state (A, B, E). We haven't sent the (A, B, D),
> > > so it is good to just replace the (A, B, D) with that. and send it
> > > when (A, B, C) is completed with either success or failure.
> > >
> > > 2) VQ_PAIRS_SET
> > >
> > > The driver starts with 1 vq pair. Now the driver sets 3 vq pairs, and
> > > the VDUSE CVQ forwards the command. The driver still thinks that it is
> > > using 1 vq pair. I can store that the driver request was 3, and it is
> > > still in-flight. Now the timeout occurs, so the VDUSE device returns
> > > fail to the driver, and the driver frees the vq regions etc. After
> > > that, the device now replies OK. The memory that was sent as the new
> > > vqs avail ring and descriptor ring now contains garbage, and it could
> > > happen that the device start overriding unrelated memory.
> > >
> > > Not even VQ_RESET protects against it as there is still a window
> > > between the CMD set and the VQ reset.
> >
> > Timeouts should be up to userspace. If userspace times out
> > and then gets confused, kernel is not to blame.
> >
> >
> 
> I meant the virtio-net driver will be confused.