On Tue, Feb 08, 2022 at 02:42:41PM +0800, Yongji Xie wrote: > On Mon, Feb 7, 2022 at 10:01 PM Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > > On Tue, Jan 25, 2022 at 09:17:57PM +0800, Xie Yongji wrote: > > > +int vduse_dev_handler(VduseDev *dev) > > > +{ > > > + struct vduse_dev_request req; > > > + struct vduse_dev_response resp = { 0 }; > > > + VduseVirtq *vq; > > > + int i, ret; > > > + > > > + ret = read(dev->fd, &req, sizeof(req)); > > > > This file descriptor is blocking? I guess the assumption is that the > > kernel VDUSE code always enqueues at least one struct vduse_dev_request, > > so userspace will not block when the file descriptor becomes readable? > > > > Yes, that's true. We can always get one entire request if the file > descriptor becomes readable.
Okay, then the code is fine. We trust the kernel not to block us. While it is possible to get spurious select(2)/poll(2) ready file descriptors in the general case (e.g. multiple processes monitoring the same file), I don't think that can happen in this case.
signature.asc
Description: PGP signature