Re: [PULL 08/25] vfio-user: connect vfio proxy to remote server

[John Levon <levon@movementarian.org>]

On Thu, Jul 10, 2025 at 01:33:17PM +0100, Peter Maydell wrote:

> On Thu, 26 Jun 2025 at 08:51, Cédric Le Goater <clg@redhat.com> wrote:
> >
> > From: John Levon <john.levon@nutanix.com>
> >
> > Introduce the vfio-user "proxy": this is the client code responsible for
> > sending and receiving vfio-user messages across the control socket.
> >
> > The new files hw/vfio-user/proxy.[ch] contain some basic plumbing for
> > managing the proxy; initialize the proxy during realization of the
> > VFIOUserPCIDevice instance.
> 
> Hi; Coverity points out an issue with this code (CID 1611806):

Cédric sent me the reports separately. They are (as far as I'm able to tell
without a coverity login) all false positives, except the uninitialized variable
one which I have sent a patch for.

The locking reports don't realize the proxy->lock is already held.

> > +     * Make sure the iothread isn't blocking anywhere
> > +     * with a ref to this proxy by waiting for a BH
> > +     * handler to run after the proxy fd handlers were
> > +     * deleted above.
> > +     */
> > +    aio_bh_schedule_oneshot(proxy->ctx, vfio_user_cb, proxy);
> > +    qemu_cond_wait(&proxy->close_cv, &proxy->lock);
> 
> qemu_cond_wait() has essentially the same semantics as
> pthread_cond_wait(), for which it is a wrapper.
> pthread_cond_wait() is allowed to wake up spuriously, so
> any use of it must be in a loop that checks for whatever
> the actual thing you were waiting for was:
>   while (something) {
>       qemu_cond_wait(...);
>   }
> 
> What is the condition this code should be checking ?

But rethinking about this one, it's theoretically possible, I suppose, if we
happen get a signal before we actually close. I'll figure out a patch, thanks.

regards
john