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):
> +void vfio_user_disconnect(VFIOUserProxy *proxy)
> +{
> + VFIOUserMsg *r1, *r2;
> +
> + qemu_mutex_lock(&proxy->lock);
[...]
> + /*
> + * 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 ?
thanks
-- PMM
