similar to: [PATCH v3 00/13] virtio-fs: shared file system for virtual machines

On Tue, Sep 03, 2019 at 10:05:02AM +0200, Miklos Szeredi wrote: > [Cc: virtualization at lists.linux-foundation.org, "Michael S. Tsirkin" > <mst at redhat.com>, Jason Wang <jasowang at redhat.com>] > > It'd be nice to have an ACK for this from the virtio maintainers. > > Thanks, > Miklos Can the patches themselves be posted to the relevant list(s)

On Tue, Sep 03, 2019 at 10:05:02AM +0200, Miklos Szeredi wrote: > [Cc: virtualization at lists.linux-foundation.org, "Michael S. Tsirkin" > <mst at redhat.com>, Jason Wang <jasowang at redhat.com>] > > It'd be nice to have an ACK for this from the virtio maintainers. > > Thanks, > Miklos Can the patches themselves be posted to the relevant list(s)

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

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

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

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

On Thu, Sep 12, 2019 at 10:14:11AM +0200, Miklos Szeredi wrote: > On Wed, Sep 11, 2019 at 5:54 PM Stefan Hajnoczi <stefanha at redhat.com> wrote: > > > > On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > > > I've folded the series from Vivek and fixed a couple of TODO comments > > > myself. AFAICS two issues remain that need to be

On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > Git tree for this version is available here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5 > > Only post patches that actually add virtiofs (virtiofs-v5-base..virtiofs-v5). > > I've folded the series from Vivek and fixed a couple of TODO comments > myself. AFAICS two

On Sun, Sep 08, 2019 at 07:53:55PM +0800, piaojun wrote: > > > On 2019/9/6 19:52, Miklos Szeredi wrote: > > On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi <stefanha at redhat.com> 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 at redhat.com> wrote:

Soon I will make virtio_fs object reference counted, where reference will be taken by device as well as by fuse_conn (fuse_conn->fuse_iqueue->fiq_priv). When fuse_connection is going away, it should put its reference on virtio_fs object. So add a fuse_iqueue method which can be used to call into virtio_fs to put the reference on the object (fiq_priv). Signed-off-by: Vivek Goyal <vgoyal

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

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 Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > Git tree for this version is available here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5 > > Only post patches that actually add virtiofs (virtiofs-v5-base..virtiofs-v5). > > I've folded the series from Vivek and fixed a couple of TODO comments > myself. AFAICS two

On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > I've folded the series from Vivek and fixed a couple of TODO comments > myself. AFAICS two issues remain that need to be resolved in the short > term, one way or the other: freeze/restore and full virtqueue. I have researched freeze/restore and come to the conclusion that it needs to be a future feature. It will

On Fri, Sep 06, 2019 at 01:05:34PM +0100, Stefan Hajnoczi wrote: > 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:

On Thu, Oct 03, 2019 at 10:42:44AM +0200, Miklos Szeredi wrote: > On Wed, Oct 2, 2019 at 3:27 PM Vivek Goyal <vgoyal at redhat.com> wrote: > > > > On Wed, Oct 02, 2019 at 09:40:11AM +0200, Miklos Szeredi wrote: > > > Looking at the ugly retry logic in virtiofs and have some questions. > > > > Hi Miklos, > > > > What are you thinking w.r.t

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 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/fs/fuse/virtio_fs.c

On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: > On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > Endian-ness for fuse header also looks wrong. [...] > > +struct virtio_fs_forget { > > + struct fuse_in_header ih; > > + struct fuse_forget_in arg; > > These structures are all native endian. > > Passing them to host will make