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 <[email protected]> wrote:
> >
> > From: John Levon <[email protected]>
> >
> > 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
