search for: virtiof

...t; > I have basically run bunch of fio jobs to get a sense of speed of > > various operations. I wrote a simple wrapper script to run fio jobs > > 3 times and take their average and report it. These scripts are available > > here. > > > > https://github.com/rhvgoyal/virtiofs-tests > > > > I set up a directory on ramfs on host and exported that directory inside > > guest using virtio-9p and virtio-fs and ran tests inside guests. Ran > > tests with cache=none both for virtio-9p and virtio-fs so that no caching > > happens in guest. For virt...

...t; > I have basically run bunch of fio jobs to get a sense of speed of > > various operations. I wrote a simple wrapper script to run fio jobs > > 3 times and take their average and report it. These scripts are available > > here. > > > > https://github.com/rhvgoyal/virtiofs-tests > > > > I set up a directory on ramfs on host and exported that directory inside > > guest using virtio-9p and virtio-fs and ran tests inside guests. Ran > > tests with cache=none both for virtio-9p and virtio-fs so that no caching > > happens in guest. For virt...

We maintain a fuse device per virt queue. This fuse devices are allocated and installed during mount time and should be cleaned up when super block is going away. Device removal should not clean it. Device removal should stop queues and virtuques can go away. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 2 -- 1 file changed, 2 deletions(-) diff --git

Stop all the virt queues when device is going away. This will ensure that no new requests are submitted to virtqueue and and request will end with error -ENOTCONN. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index f68a25ca9e9d..90e7b2f345e5 100644 ---

Hi Miklos, Here are few small cleanups for virtiofs for 5.5. I had received some comments from Michael Tsirkin on original virtiofs patches and these cleanups are result of these comments. Thanks Vivek Vivek Goyal (3): virtiofs: Use a common function to send forget virtiofs: Do not send forget request "struct list_head" element vi...

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. virsh qemu-monitor-command --hmp vm9-f28 device_del myvirtiofs Now a mounted device can be removed and file system will return errors -ENOTCONN and one can unmount it. Miklos, if you are fine w...

fs/fuse/virtio_fs.c:983:20: warning: variable fc set but not used [-Wunused-but-set-variable] It is not used since commit 7ee1e2e631db ("virtiofs: No need to check fpq->connected state") Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- fs/fuse/virtio_fs.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 2de8fc0..a5c8604 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse...

...e: > Fixes gcc '-Wunused-but-set-variable' warning: > > fs/fuse/virtio_fs.c: In function virtio_fs_wake_pending_and_unlock: > fs/fuse/virtio_fs.c:983:20: warning: variable fc set but not used [-Wunused-but-set-variable] > > It is not used since commit 7ee1e2e631db ("virtiofs: > No need to check fpq->connected state") > > Reported-by: Hulk Robot <hulkci at huawei.com> > Signed-off-by: zhengbin <zhengbin13 at huawei.com> > --- > fs/fuse/virtio_fs.c | 2 -- > 1 file changed, 2 deletions(-) Only affects the linux-next tree, not...

...>> 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?...

...> > 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...

On Mon, Aug 10, 2020 at 09:29:47AM +0200, Miklos Szeredi wrote: > On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal <vgoyal at redhat.com> wrote: > > > > > Most of the changes are limited to fuse/virtiofs. There are couple > > of changes needed in generic dax infrastructure and couple of changes > > in virtio to be able to access shared memory region. > > So what's the plan for merging the different subsystems? I can take > all that into the fuse tree, but would need ACKs...

...s move to a per-device mutex in the future. That way a single > device that fails to drain/complete requests will not hang all other > virtio-fs instances. This is fine for now. Good point. For now I updated the patch so that it applies cleanly after previous two patches changed. Subject: virtiofs: Use virtio_fs_mutex for races w.r.t ->remove and mount path It is possible that a mount is in progress and device is being removed at the same time. Use virtio_fs_mutex to avoid races. This also takes care of bunch of races and removes some TODO items. Signed-off-by: Vivek Goyal <vgoyal...

.../* on virtio_fs_instances */ > > char *tag; > > struct virtio_fs_vq *vqs; > > @@ -63,6 +64,27 @@ static inline struct fuse_pqueue *vq_to_fpq(struct virtqueue *vq) > > return &vq_to_fsvq(vq)->fud->pq; > > } > > > > +static void release_virtiofs_obj(struct kref *ref) > > +{ > > + struct virtio_fs *vfs = container_of(ref, struct virtio_fs, refcount); > > + > > + kfree(vfs->vqs); > > + kfree(vfs); > > +} > > + > > +static void virtiofs_put(struct virtio_fs *fs) > > Why do the two fun...

...gt; > > > 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 goo...

...gt; > > > 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 goo...

...e instances and a lock for the list */ +/* List of virtio-fs device instances and a lock for the list. Also provides + * mutual exclusion in device removal and mounting path + */ static DEFINE_MUTEX(virtio_fs_mutex); static LIST_HEAD(virtio_fs_instances); @@ -72,17 +74,19 @@ static void release_virtiofs_obj(struct kref *ref) kfree(vfs); } +/* Make sure virtiofs_mutex is held */ static void virtiofs_put(struct virtio_fs *fs) { - mutex_lock(&virtio_fs_mutex); kref_put(&fs->refcount, release_virtiofs_obj); - mutex_unlock(&virtio_fs_mutex); } static void virtio_fs_put(stru...

From: Vivek Goyal <vgoyal at redhat.com> [ Upstream commit bb737bbe48bea9854455cb61ea1dc06e92ce586c ] In virtiofs (unlike in regular fuse) processing of async replies is serialized. This can result in a deadlock in rare corner cases when there's a circular dependency between the completion of two or more async replies. Such a deadlock can be reproduced with xfstests:generic/503 if TEST_DIR == SCRATCH_MN...

From: Vivek Goyal <vgoyal at redhat.com> [ Upstream commit bb737bbe48bea9854455cb61ea1dc06e92ce586c ] In virtiofs (unlike in regular fuse) processing of async replies is serialized. This can result in a deadlock in rare corner cases when there's a circular dependency between the completion of two or more async replies. Such a deadlock can be reproduced with xfstests:generic/503 if TEST_DIR == SCRATCH_MN...

On Thu, Sep 05, 2019 at 03:48:55PM -0400, Vivek Goyal wrote: > diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h > index 85e2dcad68c1..04e2c000d63f 100644 > --- a/fs/fuse/fuse_i.h > +++ b/fs/fuse/fuse_i.h > @@ -479,6 +479,11 @@ struct fuse_iqueue_ops { > */ > void (*wake_pending_and_unlock)(struct fuse_iqueue *fiq) > __releases(fiq->waitq.lock); > + > + /**

...ount; > struct list_head list; /* on virtio_fs_instances */ > char *tag; > struct virtio_fs_vq *vqs; > @@ -63,6 +64,27 @@ static inline struct fuse_pqueue *vq_to_fpq(struct virtqueue *vq) > return &vq_to_fsvq(vq)->fud->pq; > } > > +static void release_virtiofs_obj(struct kref *ref) > +{ > + struct virtio_fs *vfs = container_of(ref, struct virtio_fs, refcount); > + > + kfree(vfs->vqs); > + kfree(vfs); > +} > + > +static void virtiofs_put(struct virtio_fs *fs) Why do the two function names above contain "virtiofs" ins...