On Thu, May 11, 2023 at 10:10 AM Xia, Chenbo <chenbo....@intel.com> wrote:
> > Covscan reported:
> >
> > 2. dpdk-21.11/lib/vhost/socket.c:852: lock_acquire: Calling function
> > "pthread_mutex_lock" acquires lock "vhost_user.mutex".
> > 23. dpdk-21.11/lib/vhost/socket.c:955: sleep: Call to
> > "vhost_user_reconnect_init" might sleep while holding lock
> > "vhost_user.mutex".
> > # 953| vsocket->reconnect =
> > !(flags & RTE_VHOST_USER_NO_RECONNECT);
> > # 954| if (vsocket->reconnect && reconn_tid == 0) {
> > # 955|-> if (vhost_user_reconnect_init() != 0)
> > # 956| goto out_mutex;
> > # 957| }
> >
> > The reason for this warning is that vhost_user_reconnect_init() creates a
> > ctrl thread and calls nanosleep waiting for this thread to be ready,
> > while vhost_user.mutex is taken.
> >
> > Move the call to vhost_user_reconnect_init() out of this mutex.
> >
> > While at it, a pthread_t value should be considered opaque.
> > Instead of relying reconn_tid == 0, use an internal flag in
> > vhost_user_reconnect_init().
>
> Should we make reconn_tid not a global variable anymore then?
> Maybe a static pthread_t in vhost_user_reconnect_init?
Yep, I just sent a v2.
Thanks Chenbo.
--
David Marchand
