Message ID | 20190905194859.16219-19-vgoyal@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | virtiofs: Fix various races and cleanups round 1 | expand |
On Thu, Sep 05, 2019 at 03:48:59PM -0400, Vivek Goyal wrote: > virtio_fs_free_devs() is now called from ->kill_sb(). By this time > all device queues have been quiesced. I am assuming that while > ->kill_sb() is in progress, another mount instance will wait for > it to finish (sb->s_umount mutex provides mutual exclusion). > > W.r.t ->remove path, we should be fine as we are not touching vdev > or virtqueues. And we have reference on virtio_fs object, so we know > rest of the data structures are valid. > > So I can't see the need of any additional locking yet. > > Signed-off-by: Vivek Goyal <vgoyal@redhat.com> > --- > fs/fuse/virtio_fs.c | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index eadaea6eb8e2..61aa3eba7b22 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -200,8 +200,6 @@ static void virtio_fs_free_devs(struct virtio_fs *fs) { unsigned int i; - /* TODO lock */ - for (i = 0; i < fs->nvqs; i++) { struct virtio_fs_vq *fsvq = &fs->vqs[i];
virtio_fs_free_devs() is now called from ->kill_sb(). By this time all device queues have been quiesced. I am assuming that while ->kill_sb() is in progress, another mount instance will wait for it to finish (sb->s_umount mutex provides mutual exclusion). W.r.t ->remove path, we should be fine as we are not touching vdev or virtqueues. And we have reference on virtio_fs object, so we know rest of the data structures are valid. So I can't see the need of any additional locking yet. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> --- fs/fuse/virtio_fs.c | 2 -- 1 file changed, 2 deletions(-)