[Virtio-fs] [PATCH] virtiofsd: Fix lo_destroy crash in g_hash_table_foreach_remove

[Stefan Hajnoczi]

On Thu, Aug 08, 2019 at 11:26:51AM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefanha at redhat.com) wrote:
> > On Wed, Aug 07, 2019 at 09:29:55AM -0400, Vivek Goyal wrote:
> > > On Wed, Aug 07, 2019 at 02:17:15PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Vivek Goyal (vgoyal at redhat.com) wrote:
> > > > > On Wed, Aug 07, 2019 at 10:31:52AM +0100, Dr. David Alan Gilbert (git) wrote:
> > > > > - Also before destroying lo, should we sever connection so that any
> > > > >   requests which come after lo_destroy() are not entertained.
> > > > 
> > > > No, because in some situations lo_destroy does not happen at the end;
> > > > e.g. it happens during a umount and we still have the connection
> > > > to be able to remount it.
> > > 
> > > Ok, so we don't sever the connection completely. But we don't expect to
> > > process further requests till a new INIT has been done, isn't it?
> > > 
> > > IOW, once lo_destroy() is received, we cleanup any pending state from
> > > the mount and if any requests are received from client, we error them
> > > out.
> > > 
> > > And start processing requests normally when a new INIT has been
> > > received.
> > > 
> > > Atleast that was my understanding of the design.
> > 
> > There is a state machine that does:
> > 
> > 1. Drain in-flight requests when DESTROY is received.
> 
> Hmm does that drain happen in the reboot case where there wasn't
> actually a destroy message? (fuse_session_process_buf_int 
> where it calls se->op.destroy explicitly)

struct fuse_session::init_rwlock has these semantics:

INIT and DESTROY requests acquire a write lock.  All other requests
acquire a read lock.

A write lock must wait for in-progress readers to complete.  This is the
drain.  New readers must wait for writers (even for waiting writers, to
ensure fairness).

In the reboot case INIT message acts as the drain operation.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20190809/7f506e47/attachment.sig>