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
