On Fri, Sep 6, 2019 at 3:57 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Fri, Sep 06, 2019 at 08:08:17AM -0400, Vivek Goyal wrote: > > On Fri, Sep 06, 2019 at 01:52:41PM +0200, Miklos Szeredi wrote: > > > On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Sep 06, 2019 at 10:15:14AM +0200, Miklos Szeredi wrote: > > > > > On Thu, Sep 5, 2019 at 9:49 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Michael Tsirkin pointed out issues w.r.t various locking related TODO > > > > > > items and races w.r.t device removal. > > > > > > > > > > > > In this first round of cleanups, I have taken care of most pressing > > > > > > issues. > > > > > > > > > > > > These patches apply on top of following. > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v4 > > > > > > > > > > > > I have tested these patches with mount/umount and device removal using > > > > > > qemu monitor. For example. > > > > > > > > > > Is device removal mandatory? Can't this be made a non-removable > > > > > device? Is there a good reason why removing the virtio-fs device > > > > > makes sense? > > > > > > > > Hot plugging and unplugging virtio PCI adapters is common. I'd very > > > > much like removal to work from the beginning. > > > > > > Can you give an example use case? > > > > David Gilbert mentioned this could be useful if daemon stops responding > > or dies. One could remove device. That will fail all future requests > > and allow unmounting filesystem. > > > > Havind said that, current implementation will help in above situation > > only if there are no pending requests. If there are pending requests > > and daemon stops responding, then removal will hang too, as we wait > > for draining the queues. > > > > So at some point of time, we also need some sort of timeout functionality > > where we end requests with error after a timeout. > > > > I feel we should support removing device at some point of time. But its > > not necessarily a must have feature for first round. > > > > Thanks > > Vivek > > Without removal how do we stop guest poking at some files if we want to? > > I guess we could invent a special event to block accesses, > but unplug will just do it. > > blk and scsi support removal out of box, if this is supposed > to be a drop in replacement then I think yes, you want this > support. This is not a drop in replacement for blk and scsi transports. More for virtio-9p. Does that have anything similar? If we get a request for this feature, then yes, what you are saying makes sense. But that hasn't happened yet, so I think this can wait. Thanks, Miklos
