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

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] [day] [month] [year] [list]

Message-ID: <CAJaqyWcyJU_ghJpQrnEyTf19o_NzE6FXkxgBRZx=1RYqQkN4gA@mail.gmail.com>
Date: Fri, 17 Oct 2025 09:21:17 +0200
From: Eugenio Perez Martin <eperezma@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Jason Wang <jasowang@...hat.com>, Maxime Coquelin <mcoqueli@...hat.com>, 
	Yongji Xie <xieyongji@...edance.com>, virtualization@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
	Dragos Tatulea DE <dtatulea@...dia.com>
Subject: Re: [RFC 1/2] virtio_net: timeout control virtqueue commands

On Fri, Oct 17, 2025 at 8:39 AM Michael S. Tsirkin <mst@...hat.com> wrote:
>
> On Fri, Oct 17, 2025 at 08:36:41AM +0200, Eugenio Perez Martin wrote:
> > On Thu, Oct 16, 2025 at 8:25 AM Eugenio Perez Martin
> > <eperezma@...hat.com> wrote:
> > >
> > > On Thu, Oct 16, 2025 at 8:22 AM Michael S. Tsirkin <mst@...hat.com> wrote:
> > > >
> > > > On Thu, Oct 16, 2025 at 02:03:57PM +0800, Jason Wang wrote:
> > > > > On Thu, Oct 16, 2025 at 1:45 PM Michael S. Tsirkin <mst@...hat.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 16, 2025 at 01:39:58PM +0800, Jason Wang wrote:
> > > > > > > > >
> > > > > > > > > Not exactly bufferize, record.  E.g. we do not need to send
> > > > > > > > > 100 messages to enable/disable promisc mode - together they
> > > > > > > > > have no effect.
> > > > > > >
> > > > > > > Note that there's a case that multiple commands need to be sent, e.g
> > > > > > > set rx mode. And assuming not all the commands are the best effort,
> > > > > > > kernel VDUSE still needs to wait for the usersapce at least for a
> > > > > > > while.
> > > > > >
> > > > > > Not wait, record. Generate 1st command, after userspace consumed it -
> > > > > > generate and send second command and so on.
> > > > >
> > > > > Right, that's what I asked in another thread, we still need a timeout
> > > > > here.
> > > >
> > > > we do not need a timeout.
> > > >
> > > > > Then I think it would not be too much difference whether it is
> > > > > VDUSE or CVQ that will fail or break the device. Conceptually, VDUSE
> > > > > can only advertise NEEDS_RESET since it's a device implementation.
> > > > > VDUSE can not simply break the device as it requires synchronization
> > > > > which is not easy.
> > > > >
> > > > > > But for each bit of data, at most one command has to be sent,
> > > > > > we do not care if guest tweaked rx mode 3 times, we only care about
> > > > > > the latest state.
> > > > >
> > > > > Yes, but I want to know what's best when VDUSE meets userspace timeout.
> > > > >
> > > > > Thanks
> > > >
> > > >
> > > > userspace should manage its own timeouts.
> > > >
> > >
> > > Can we just apply the patch 2/2 of this RFC directly and apply the
> > > VDUSE CVQ on top then? What are we missing to do it?
> > >
> >
> > Even better, can we just revert commit 56e71885b0349 ("vduse:
> > Temporarily fail if control queue feature requested") ?
>
> No because both would let userspace hang kernels merely by
> not consuming buffers.
>

My understanding was that you want to be able to debug qemu with gdb
from that hang [1].

Could you put an example of the whole chain of events you expect? From
the moment the driver sends a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command,
the VDUSE CVQ Forwards the command to the VDUSE device in the
userspace, and then the vduse userland device does not reply.

How does the VDUSE CVQ detect that the VDUSE device implemented in
userland does not reply? What are the next steps from that point of
the kernel VDUSE module?

Thanks!

[1] https://lore.kernel.org/lkml/20251014042459-mutt-send-email-mst@kernel.org/