similar to: [PATCH 0/5] virtiofs: Fix couple of deadlocks

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

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

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 virtiofs: Use completions while waiting for queue

On Thu, Sep 05, 2019 at 03:15:15PM -0400, Vivek Goyal wrote: > On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: > [..] > > What's with all of the TODOs? Some of these are really scary, > > looks like they need to be figured out before this is merged. > > Hi Michael, > > One of the issue I noticed is races w.r.t device removal and super >

When the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 40us baseline without going to a remote server (4k, QD=1). This patch queues requests when the Virtio queue is full, and when a completed request is taken off,

When the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 40us baseline without going to a remote server (4k, QD=1). This patch queues requests when the Virtio queue is full, and when a completed request is taken off,

On Wed, May 31, 2023 at 04:49:39PM -0400, Vivek Goyal wrote: > On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: > > On 31/05/2023 21:18, Vivek Goyal wrote: > > > On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: > > >> When the Virtio queue is full, a work item is scheduled > > >> to execute in 1ms that retries adding the

On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: > On 31/05/2023 21:18, Vivek Goyal wrote: > > On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: > >> When the Virtio queue is full, a work item is scheduled > >> to execute in 1ms that retries adding the request to the queue. > >> This is a large amount of time on the scale on

On 01/06/2023 16:08, Stefan Hajnoczi wrote: > On Wed, May 31, 2023 at 04:49:39PM -0400, Vivek Goyal wrote: >> On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: >>> On 31/05/2023 21:18, Vivek Goyal wrote: >>>> On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: >>>>> When the Virtio queue is full, a work item is scheduled

When the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 40us baseline without going to a remote server (4k, QD=1). This patch queues requests when the Virtio queue is full, and when a completed request is taken off,

On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote: > This object is used both by fuse_connection as well virt device. So make > this object reference counted and that makes it easy to define life cycle > of the object. > > Now deivce can be removed while filesystem is still mounted. This will > cleanup all the virtqueues but virtio_fs object will still be around and

On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote: > This object is used both by fuse_connection as well virt device. So make > this object reference counted and that makes it easy to define life cycle > of the object. > > Now deivce can be removed while filesystem is still mounted. This will > cleanup all the virtqueues but virtio_fs object will still be around and

On Thu, Sep 05, 2019 at 03:48:57PM -0400, Vivek Goyal wrote: > 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 at redhat.com> > --- > fs/fuse/virtio_fs.c | 32

On Thu, Sep 05, 2019 at 03:48:57PM -0400, Vivek Goyal wrote: > 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 at redhat.com> > --- > fs/fuse/virtio_fs.c | 32

On Thu, Sep 12, 2019 at 04:19:31PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Michael, > > Here's a v6 of the virtiofs code (fuse.git#virtiofs-v6). I think we've > addressed all your comments. > > Would you mind giving it another look, and if you're satisfied acking this > patch? > > Thanks, > Miklos

On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: [..] > What's with all of the TODOs? Some of these are really scary, > looks like they need to be figured out before this is merged. Hi Michael, One of the issue I noticed is races w.r.t device removal and super block initialization. I am about to post a set of patches which take care of these races and also get rid of

On Mon, Oct 21, 2019 at 10:03:39AM +0200, Miklos Szeredi wrote: [..] > > static void virtio_fs_hiprio_dispatch_work(struct work_struct *work) > > @@ -502,6 +522,7 @@ static int virtio_fs_setup_vqs(struct virtio_device *vdev, > > names[VQ_HIPRIO] = fs->vqs[VQ_HIPRIO].name; > > INIT_WORK(&fs->vqs[VQ_HIPRIO].done_work, virtio_fs_hiprio_done_work);

If virtqueue is full, we put forget requests on a list and these forgets are dispatched later using a worker. As of now we don't count these forgets in fsvq->in_flight variable. This means when queue is being drained, we have to have special logic to first drain these pending requests and then wait for fsvq->in_flight to go to zero. By counting pending forgets in fsvq->in_flight, we

While we wait for queue to finish draining, use completions instead of uslee_range(). This is better way of waiting for event. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 39 +++++++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 43224db8d9ed..b5ba83ef1914 100644