What are libvhost-user locking requirements

[Vivek Goyal]

Hi,

Current virtiofsd code uses libvhost-user and I am assuming virtiofsd-rs
uses it too. I am wondering what are the locking requirements for
this library.

Looking at it it does not look like thread safe. Well parts of of kind
of look thread safe. For example, David Gilbert introduced a slave_mutex
to control reading/writeing on slave_fd. But dev->slave_fd can be modified
vu_set_slave_req_fd() without any locks. Similiarly _vu_queue_notify()
uses dev->slave_fd but  does not take any lock. May be these are just
bugs and we can take slave_mutex in those paths so not a big deal.

But this library does not talk about locking at all. Of course there
are many shared data structures like "struct VuDev" and helpers which
access this structure. Is client supposed to provide locking and
make sure not more than one thread is calling into the library
at one point of time.

But in virtiofsd I see that we seem to be in mixed mode. In some cases
we are holding ->vu_dispatch_rwlock in read-only mode. So that will
allow multipler threads to call into library for one queue.

In other places like lo_setupmapping() and lo_removemapping(), we are
not holding ->vu_dispatch_rwlock() at all and simply call into
library vu_fs_cache_request(VHOST_USER_SLAVE_FS_MAP/...). So multiple
threads can call in. I think precisely for this use case dev->slave_mutex
has been introduced in library.

So few queries.

- what's the locking model needed to use libvhost-user. Is there one? 

- Is it ok to selectively add locking for some data structures in
  libvhost-user. As slave_mutex has been added. So user will have to
  go through the code to figure out which paths can be called without
  locks and which paths can't be.

/me is confused and trying to wrap my head around the locking requirements
while using libvhost-user.

Vivek