On Mon, Jul 03, 2023 at 09:14:59PM +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 which a
> virtio-fs device can operate. When using a DPU
On Fri, Jun 02, 2023 at 03:32:26PM +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 which a
> virtio-fs device can operate. When using a DPU
On Thu, Jun 01, 2023 at 10:08:50AM -0400, 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, Ma
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
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 which a
> virtio-fs device can operate. When using a DPU
at 09:33:33AM +0100, Peter-Jan Gootzen wrote:
> > > > >
> > > > >
> > > > > On 07/02/2023 22:57, Vivek Goyal wrote:
> > > > > > On Tue, Feb 07, 2023 at 04:32:02PM -0500, Stefan Hajnoczi wrote:
> > > > > > > On Tue, Feb
On Mon, Feb 27, 2023 at 10:53:45AM -0500, Stefan Hajnoczi wrote:
> On Fri, Feb 24, 2023 at 03:37:51PM +0100, David Heidelberg wrote:
> > From: Stefan Hajnoczi
> >
> > Make it possible to boot directly from a virtiofs file system with tag
> > 'myfs' using the following kernel parameters:
> >
> >
On Wed, Feb 08, 2023 at 05:29:25PM +0100, Peter-Jan Gootzen wrote:
> On 08/02/2023 11:43, Stefan Hajnoczi wrote:
> > On Wed, Feb 08, 2023 at 09:33:33AM +0100, Peter-Jan Gootzen wrote:
> > >
> > >
> > > On 07/02/2023 22:57, Vivek Goyal wrote:
> > &g
On Tue, Feb 07, 2023 at 04:32:02PM -0500, Stefan Hajnoczi wrote:
> On Tue, Feb 07, 2023 at 02:53:58PM -0500, Vivek Goyal wrote:
> > On Tue, Feb 07, 2023 at 02:45:39PM -0500, Stefan Hajnoczi wrote:
> > > On Tue, Feb 07, 2023 at 11:14:46AM +0100, Peter-Jan Gootzen
On Tue, Feb 07, 2023 at 02:45:39PM -0500, Stefan Hajnoczi wrote:
> On Tue, Feb 07, 2023 at 11:14:46AM +0100, Peter-Jan Gootzen wrote:
> > Hi,
> >
[cc German]
> > For my MSc thesis project in collaboration with IBM
> > (https://github.com/IBM/dpu-virtio-fs) we are looking to improve the
> >
On Wed, Jun 22, 2022 at 05:17:58PM -0400, Deming Wang wrote:
> We should isolate operators with spaces.
>
> Signed-off-by: Deming Wang
Looks good to me.
Reviewed-by: Vivek Goyal
Vivek
> ---
> fs/fuse/virtio_fs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
&g
is gone indeed and pjdfstests still pass. So..
Reviewed-by: Vivek Goyal
Thanks
Vivek
> ---
> fs/fuse/control.c | 4 ++--
> fs/fuse/fuse_i.h| 4
> fs/fuse/inode.c | 1 +
> fs/fuse/virtio_fs.c | 1 +
> 4 files changed, 8 insertions(+), 2 deletions(-)
>
> dif
On Wed, Jun 15, 2022 at 01:57:54PM +0800, Xie Yongji wrote:
> This gets rid of "no_control" related code since
> nobody uses it.
>
> Signed-off-by: Xie Yongji
Good to get rid of this knob. Nobody is using it.
Reviewed-by: Vivek Goyal
Vivek
> ---
> fs/fuse/fus
On Wed, Jun 15, 2022 at 01:57:55PM +0800, Xie Yongji wrote:
> Virtio-fs does not support aborting requests which are being
> processed. Otherwise, it might trigger UAF since
What is full form of UAF? Use after free?
Thanks
Vivek
> virtio_fs_request_complete() doesn't know the requests are
>
On Thu, Jun 09, 2022 at 10:08:38PM -0400, Deming Wang wrote:
> fs parameter not used. So, it needs to be deleted.
>
> Signed-off-by: Deming Wang
Thanks Deming Wang for the patch. Good cleanup.
Reviewed-by: Vivek Goyal
Thanks
Vivek
> ---
> fs/fuse/virtio_fs.c | 7 +++
&g
On Wed, Jun 08, 2022 at 09:57:51PM +0800, Yongji Xie wrote:
> On Wed, Jun 8, 2022 at 8:44 PM Vivek Goyal wrote:
> >
> > On Wed, Jun 08, 2022 at 04:42:46PM +0800, Yongji Xie wrote:
> > > On Wed, Jun 8, 2022 at 3:34 AM Vivek Goyal wrote:
> > > >
> > &g
On Wed, Jun 08, 2022 at 04:42:46PM +0800, Yongji Xie wrote:
> On Wed, Jun 8, 2022 at 3:34 AM Vivek Goyal wrote:
> >
> > On Tue, Jun 07, 2022 at 07:05:04PM +0800, Xie Yongji wrote:
> > > The commit 15c8e72e88e0 ("fuse: allow skipping control
> > > interfac
On Tue, Jun 07, 2022 at 07:05:04PM +0800, Xie Yongji wrote:
> The commit 15c8e72e88e0 ("fuse: allow skipping control
> interface and forced unmount") tries to remove the control
> interface for virtio-fs since it does not support aborting
> requests which are being processed. But it doesn't work
On Mon, Apr 11, 2022 at 03:20:05PM +0200, Bernd Schubert wrote:
>
>
> On 4/11/22 13:54, JeffleXu wrote:
> >
> >
> > On 4/11/22 7:52 PM, Vivek Goyal wrote:
> > > On Mon, Apr 11, 2022 at 10:10:23AM +0800, JeffleXu wrote:
> > > >
>
On Mon, Apr 11, 2022 at 10:10:23AM +0800, JeffleXu wrote:
>
>
> On 4/8/22 8:06 PM, Vivek Goyal wrote:
> > On Fri, Apr 08, 2022 at 07:50:55PM +0800, JeffleXu wrote:
> >>
> >>
> >> On 4/8/22 7:25 PM, Vivek Goyal wrote:
> >>> On
On Fri, Apr 08, 2022 at 07:50:55PM +0800, JeffleXu wrote:
>
>
> On 4/8/22 7:25 PM, Vivek Goyal wrote:
> > On Fri, Apr 08, 2022 at 10:36:40AM +0800, JeffleXu wrote:
> >>
> >>
> >> On 4/7/22 10:10 PM, Vivek Goyal wrote:
> >>> On Sat, Apr 02,
On Fri, Apr 08, 2022 at 10:36:40AM +0800, JeffleXu wrote:
>
>
> On 4/7/22 10:10 PM, Vivek Goyal wrote:
> > On Sat, Apr 02, 2022 at 06:32:50PM +0800, Jeffle Xu wrote:
> >> Move dmap free worker kicker inside the critical region, so that extra
> >> spin
ke sure nothing is
broken.
Reviewed-by: Vivek Goyal
Vivek
> ---
> fs/fuse/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
> index d7d3a7f06862..b9f8795d52c4 100644
> --- a/fs/fuse/dax.c
> +++ b/fs/fuse/da
On Tue, Dec 14, 2021 at 03:43:38PM -0800, Dan Williams wrote:
> On Tue, Dec 14, 2021 at 12:33 PM Vivek Goyal wrote:
> >
> > On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote:
> > > On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote:
> > > >
> &
On Wed, Dec 15, 2021 at 10:30:50AM +, Stefan Hajnoczi wrote:
> On Tue, Dec 14, 2021 at 03:32:43PM -0500, Vivek Goyal wrote:
> > On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote:
> > > On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote:
> > > >
> &g
On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote:
> On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote:
> >
> > On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote:
> > > On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote:
> > >
On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote:
> On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote:
> > On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote:
> > > Going forward, I am wondering should virtiofs use flushcache version as
> &
On Sun, Dec 12, 2021 at 06:48:05AM -0800, Dan Williams wrote:
> On Fri, Dec 10, 2021 at 6:05 AM Vivek Goyal wrote:
> >
> > On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote:
> > > While using the MC-safe copy routines is rather pointless on a virtual
On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote:
> On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote:
> >
> > On Thu, Dec 09, 2021 at 07:38:27AM +0100, Christoph Hellwig wrote:
> > > These methods indirect the actual DAX read/write path. In the end pmem
>
_to_iter,
> .zero_page_range = virtio_fs_zero_page_range,
> };
>
> @@ -853,7 +837,8 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> fs->dax_dev = alloc_dax(fs, _fs_dax_ops);
> if (IS_ERR(fs->dax_dev))
>
On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote:
> While using the MC-safe copy routines is rather pointless on a virtual device
> like virtiofs,
I was wondering about that. Is it completely pointless.
Typically we are just mapping host page cache into qemu address space.
That
On Mon, Nov 29, 2021 at 09:27:17PM +0800, Tiezhu Yang wrote:
> On 11/29/2021 06:19 PM, Stefan Hajnoczi wrote:
> > On Sat, Nov 27, 2021 at 06:13:22PM +0800, Tiezhu Yang wrote:
> > > No need to generate virtio_fs.o first and then link to virtiofs.o, just
> > > rename virtio_fs.c to virtiofs.c and
| 2 +-
> drivers/virtio/virtio_mem.c| 2 +-
> fs/fuse/virtio_fs.c | 4 ++--
fs/fuse/virtio_fs.c changes look good to me.
Reviewed-by: Vivek Goyal
Vivek
[..]
> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
> index 0ad89c6629d7..27c3b74070a2 100644
&
On Thu, Sep 16, 2021 at 04:21:59PM +0800, JeffleXu wrote:
> Hi, I add some performance statistics below.
>
>
> On 8/17/21 8:40 PM, Vivek Goyal wrote:
> > On Tue, Aug 17, 2021 at 10:32:14AM +0100, Dr. David Alan Gilbert wrote:
> >> * Miklos Szeredi (mik...@szeredi.hu)
On Tue, Sep 07, 2021 at 10:57:07AM +0200, Miklos Szeredi wrote:
> On Thu, 12 Aug 2021 at 07:46, Jeffle Xu wrote:
> >
> > From: Liu Bo
> >
> > Since %req has been removed from fpq->processing_list, no one except
> > request_wait_answer() is looking at this %req and request_wait_answer()
> > waits
On Sat, Aug 28, 2021 at 05:21:39PM +0200, Miklos Szeredi wrote:
> On Mon, Aug 16, 2021 at 11:29:02AM -0400, Vivek Goyal wrote:
> > On Sun, Aug 15, 2021 at 05:14:06PM +0300, Amir Goldstein wrote:
>
> > > I wonder - even if the server does not support SYNCFS or if the kernel
On Tue, Aug 17, 2021 at 10:23:44AM +0800, Jeffle Xu wrote:
> Add .ioctl() support for passthrough, in prep for the following support
> for following per-file DAX feature.
>
> Once advertising support for per-file DAX feature, virtiofsd should
> support storing FS_DAX_FL flag persistently passed
On Tue, Aug 17, 2021 at 06:15:58PM +0100, Dr. David Alan Gilbert wrote:
> * Jeffle Xu (jeffl...@linux.alibaba.com) wrote:
> > In FUSE_INIT negotiating phase, server/client should advertise if it
> > supports per-file DAX.
> >
> > Once advertising support for per-file DAX feature, virtiofsd should
On Wed, Aug 18, 2021 at 07:08:24AM +0200, Miklos Szeredi wrote:
> On Wed, 18 Aug 2021 at 05:40, JeffleXu wrote:
>
> > I'm not sure if I fully understand your idea. Then in this case, host
> > daemon only prepares 4KB while guest thinks that the whole DAX window
> > (e.g., 2MB) has been fully
On Tue, Aug 17, 2021 at 04:11:14PM +0200, Miklos Szeredi wrote:
[..]
> > As for virtiofs, Dr. David Alan Gilbert has mentioned that various files
> > may compete for limited DAX window resource.
> >
> > Besides, supporting DAX for small files can be expensive. Small files
> > can consume DAX
On Tue, Aug 17, 2021 at 09:22:53PM +0800, JeffleXu wrote:
>
>
> On 8/17/21 8:39 PM, Vivek Goyal wrote:
> > On Tue, Aug 17, 2021 at 10:06:53AM +0200, Miklos Szeredi wrote:
> >> On Tue, 17 Aug 2021 at 04:22, Jeffle Xu wrote:
> >>>
> >>> This pa
On Tue, Aug 17, 2021 at 09:08:35PM +0800, JeffleXu wrote:
>
>
> On 8/17/21 6:09 PM, Miklos Szeredi wrote:
> > On Tue, 17 Aug 2021 at 11:32, Dr. David Alan Gilbert
> > wrote:
> >>
> >> * Miklos Szeredi (mik...@szeredi.hu) wrote:
> >>> On Tue, 17 Aug 2021 at 04:22, Jeffle Xu
> >>> wrote:
>
On Tue, Aug 17, 2021 at 10:06:53AM +0200, Miklos Szeredi wrote:
> On Tue, 17 Aug 2021 at 04:22, Jeffle Xu wrote:
> >
> > This patchset adds support of per-file DAX for virtiofs, which is
> > inspired by Ira Weiny's work on ext4[1] and xfs[2].
>
> Can you please explain the background of this
On Tue, Aug 17, 2021 at 10:32:14AM +0100, Dr. David Alan Gilbert wrote:
> * Miklos Szeredi (mik...@szeredi.hu) wrote:
> > On Tue, 17 Aug 2021 at 04:22, Jeffle Xu wrote:
> > >
> > > This patchset adds support of per-file DAX for virtiofs, which is
> > > inspired by Ira Weiny's work on ext4[1] and
On Mon, Aug 16, 2021 at 09:57:08PM +0300, Amir Goldstein wrote:
> On Mon, Aug 16, 2021 at 6:29 PM Vivek Goyal wrote:
> >
> > On Sun, Aug 15, 2021 at 05:14:06PM +0300, Amir Goldstein wrote:
> > > Hi Greg,
> > >
> > > Sorry for the late repl
On Sun, Aug 15, 2021 at 05:14:06PM +0300, Amir Goldstein wrote:
> Hi Greg,
>
> Sorry for the late reply, I have some questions about this change...
>
> On Fri, May 21, 2021 at 9:12 AM Greg Kurz wrote:
> >
> > Even if POSIX doesn't mandate it, linux users legitimately expect
> > sync() to flush
On Wed, Jul 21, 2021 at 08:48:57AM -0400, Vivek Goyal wrote:
[..]
> > > So is "dax=inode" enough for your needs? What's your requirement,
> > > can you give little bit of more details.
> >
> > In our use case, the backend fs is something like SquashFS on h
On Wed, Jul 21, 2021 at 10:14:44PM +0800, JeffleXu wrote:
[..]
> > Also, please copy virtiofs list (virtio...@redhat.com) when you post
> > patches next time.
> >
>
> Got it. By the way, what's the git repository of virtiofsd? AFAIK,
> virtiofsd included in qemu (g...@github.com:qemu/qemu.git)
On Wed, Jul 21, 2021 at 08:32:19PM +0800, JeffleXu wrote:
>
>
> On 7/21/21 3:18 AM, Vivek Goyal wrote:
> > On Tue, Jul 20, 2021 at 01:25:11PM +0800, JeffleXu wrote:
> >>
> >>
> >> On 7/20/21 5:30 AM, Vivek Goyal wrote:
> >>> On
On Tue, Jul 20, 2021 at 03:19:50PM +0800, JeffleXu wrote:
>
>
> On 7/20/21 2:41 AM, Vivek Goyal wrote:
> > On Fri, Jul 16, 2021 at 06:47:52PM +0800, Jeffle Xu wrote:
> >> Add one flag for fuse_attr.flags indicating if DAX shall be enabled for
> >> this file.
>
On Tue, Jul 20, 2021 at 02:51:34PM +0800, JeffleXu wrote:
>
>
> On 7/20/21 3:44 AM, Vivek Goyal wrote:
> > On Fri, Jul 16, 2021 at 06:47:52PM +0800, Jeffle Xu wrote:
> >> Add one flag for fuse_attr.flags indicating if DAX shall be enabled for
> >> this file.
>
On Tue, Jul 20, 2021 at 01:25:11PM +0800, JeffleXu wrote:
>
>
> On 7/20/21 5:30 AM, Vivek Goyal wrote:
> > On Fri, Jul 16, 2021 at 06:47:49PM +0800, Jeffle Xu wrote:
> >> This patchset adds support of per-file DAX for virtiofs, which is
> >> inspired by Ira
On Fri, Jul 16, 2021 at 06:47:49PM +0800, Jeffle Xu wrote:
> This patchset adds support of per-file DAX for virtiofs, which is
> inspired by Ira Weiny's work on ext4[1] and xfs[2].
>
> There are three related scenarios:
> 1. Alloc inode: get per-file DAX flag from fuse_attr.flags. (patch 3)
> 2.
On Fri, Jul 16, 2021 at 06:47:53PM +0800, Jeffle Xu wrote:
> Fuse client can enable or disable per-file DAX inside guest by
> chattr(1). Similarly the new state won't be updated until the file is
> closed and reopened later.
>
> It is worth nothing that it is a best-effort style, since whether
>
On Fri, Jul 16, 2021 at 06:47:52PM +0800, Jeffle Xu wrote:
> Add one flag for fuse_attr.flags indicating if DAX shall be enabled for
> this file.
>
> When the per-file DAX flag changes for an *opened* file, the state of
> the file won't be updated until this file is closed and reopened later.
>
On Fri, Jul 16, 2021 at 06:47:52PM +0800, Jeffle Xu wrote:
> Add one flag for fuse_attr.flags indicating if DAX shall be enabled for
> this file.
>
> When the per-file DAX flag changes for an *opened* file, the state of
> the file won't be updated until this file is closed and reopened later.
>
On Fri, Jul 16, 2021 at 06:47:51PM +0800, Jeffle Xu wrote:
> We add 'always', 'never', and 'inode' (default). '-o dax' continues to
> operate the same which is equivalent to 'always'.
>
> By the time this patch is applied, 'inode' mode is actually equal to
> 'always' mode, before the per-file DAX
On Fri, Jul 16, 2021 at 09:18:34AM +0800, JeffleXu wrote:
>
>
> On 7/16/21 8:51 AM, Vivek Goyal wrote:
> > On Fri, Jul 16, 2021 at 08:40:29AM +0800, Liu Bo wrote:
> >> On Thu, Jul 15, 2021 at 05:30:31PM +0800, Jeffle Xu wrote:
> >>> Add one flag for fus
On Fri, Jul 16, 2021 at 08:40:29AM +0800, Liu Bo wrote:
> On Thu, Jul 15, 2021 at 05:30:31PM +0800, Jeffle Xu wrote:
> > Add one flag for fuse_attr.flags indicating if DAX shall be enabled for
> > this file.
> >
> > When the per-file DAX flag changes for an *opened* file, the state of
> > the
On Mon, May 10, 2021 at 11:15:21AM -0500, Connor Kuehl wrote:
> On 5/10/21 10:25 AM, Vivek Goyal wrote:
> > On Fri, May 07, 2021 at 03:15:27PM -0700, Connor Kuehl wrote:
> >> Distribute requests across the multiqueue complex automatically based
> >> on the IRQ a
On Fri, May 07, 2021 at 03:15:27PM -0700, Connor Kuehl wrote:
> Distribute requests across the multiqueue complex automatically based
> on the IRQ affinity.
Hi Connor,
Thanks for the patch. I will look into it and also test it.
How did you test it? Did you modify vitiofsd to support multiqueue.
On Tue, Apr 27, 2021 at 09:09:21PM +0200, Greg Kurz wrote:
[..]
> > > diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> > > index 54442612c48b..1265ca17620c 100644
> > > --- a/include/uapi/linux/fuse.h
> > > +++ b/include/uapi/linux/fuse.h
> > > @@ -179,6 +179,9 @@
> > > *
On Mon, Apr 26, 2021 at 05:10:11PM +0200, Greg Kurz wrote:
> Even if POSIX doesn't mandate it, linux users legitimately expect
> sync() to flush all data and metadata to physical storage when it
> is located on the same system. This isn't happening with virtiofs
> though : sync() inside the guest
On Mon, Apr 19, 2021 at 05:08:48PM +0200, Greg Kurz wrote:
> Even if POSIX doesn't mandate it, linux users legitimately expect
> sync() to flush all data and metadata to physical storage when it
> is located on the same system. This isn't happening with virtiofs
> though : sync() inside the guest
On Tue, Apr 06, 2021 at 06:53:32PM -0500, Aditya Pakki wrote:
> In virtio_fs_get_tree, after fm is freed, it is again freed in case
> s_root is NULL and virtio_fs_fill_super() returns an error. To avoid
> a double free, set fm to NULL.
>
> Signed-off-by: Aditya Pakki
> ---
> fs/fuse/virtio_fs.c
On Mon, Mar 22, 2021 at 10:18:31PM -0700, Lv Yunlong wrote:
> In virtio_fs_get_tree, fm is allocated by kzalloc() and
> assigned to fsc->s_fs_info by fsc->s_fs_info=fm statement.
> If the kzalloc() failed, it will goto err directly, so that
> fsc->s_fs_info must be non-NULL and fm will be freed.
ealistically fit on the virtqueue
> when it is decomposed into a scattergather list and avoid violating section
> 2.6.5.3.1 of the virtio spec.
>
> Signed-off-by: Connor Kuehl
> Signed-off-by: Miklos Szeredi
> ---
Looks good to me.
Reviewed-by: Vivek Goyal
Vivek
> fs/fuse/fuse_i
On Thu, Mar 18, 2021 at 08:52:22AM -0500, Connor Kuehl wrote:
> If an incoming FUSE request can't fit on the virtqueue, the request is
> placed onto a workqueue so a worker can try to resubmit it later where
> there will (hopefully) be space for it next time.
>
> This is fine for requests that
On Wed, Mar 17, 2021 at 01:12:01PM -0500, Connor Kuehl wrote:
> Hi,
>
> I've been familiarizing myself with the virtiofs guest kernel module and I'm
> trying to better understand how virtiofs maps a FUSE request into
> scattergather lists.
>
> sg_count_fuse_req() starts knowing that there will
_sys_finit_module+0xb5/0x120
> [<ad2f48c6>] do_syscall_64+0x33/0x40
> [<809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Luis Henriques
Reviewed-by: Vivek Goyal
Thanks
Vivek
> ---
> Changes since v1:
On Tue, Mar 16, 2021 at 05:02:34PM +, Luis Henriques wrote:
> When accidentally passing twice the same tag to qemu, kmemleak ended up
> reporting a memory leak in virtiofs. Also, looking at the log I saw the
> following error (that's when I realised the duplicated tag):
>
> virtiofs: probe
From: Sebastien Boeuf
On PCI the shm regions are found using capability entries;
find a region by searching for the capability.
Signed-off-by: Sebastien Boeuf
Signed-off-by: Dr. David Alan Gilbert
Signed-off-by: kbuild test robot
Acked-by: Michael S. Tsirkin
Cc: k...@vger.kernel.org
Cc:
From: Sebastien Boeuf
On MMIO a new set of registers is defined for finding SHM
regions. Add their definitions and use them to find the region.
Signed-off-by: Sebastien Boeuf
Cc: k...@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: "Michael S. Tsirkin"
---
From: Sebastien Boeuf
Virtio defines 'shared memory regions' that provide a continuously
shared region between the host and guest.
Provide a method to find a particular region on a device.
Signed-off-by: Sebastien Boeuf
Signed-off-by: Dr. David Alan Gilbert
Acked-by: Michael S. Tsirkin
Cc:
On Mon, Aug 10, 2020 at 09:29:47AM +0200, Miklos Szeredi wrote:
> On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal wrote:
> >
>
> > Most of the changes are limited to fuse/virtiofs. There are couple
> > of changes needed in generic dax infrastructure and couple of changes
On Wed, Aug 05, 2020 at 09:44:39AM -0400, Michael S. Tsirkin wrote:
> Virtio fs is modern-only. Use LE accessors for config space.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Vivek Goyal
Vivek
> ---
> fs/fuse/virtio_fs.c | 4 ++--
> 1 file changed, 2 insertio
On Mon, Aug 03, 2020 at 04:59:13PM -0400, Michael S. Tsirkin wrote:
> Since fs is a modern-only device,
> tag config space fields as having little endian-ness.
>
> Signed-off-by: Michael S. Tsirkin
virtio spec does list this field as "le32".
Acked-by: Vivek Goyal
Vivek
:1029:1: warning: ‘static’ is not at beginning of
> declaration [-Wold-style-declaration]
> const static struct fuse_iqueue_ops virtio_fs_fiq_ops = {
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
Acked-by: Vivek Goyal
Vivek
> ---
> v1->v2: modify comment
> fs/fu
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
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
---
fs/fuse/virtio_fs.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/fs/fuse
Currently we are duplicating logic to send forgets at two places. Consolidate
the code by calling one helper function.
This also uses virtqueue_add_outbuf() instead of virtqueue_add_sgs(). Former
is simpler to call.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 150
We are sending whole of virtio_fs_foreget struct to the other end over
virtqueue. Other end does not need to see elements like "struct list".
That's internal detail of guest kernel. Fix it.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 17 -
1 file changed, 12
On Mon, Oct 21, 2019 at 10:15:18AM +0200, Miklos Szeredi wrote:
[..]
> > @@ -268,13 +272,43 @@ static void virtio_fs_request_dispatch_work(struct
> > work_struct *work)
> >list);
> > if (!req) {
> >
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;
> >
est queue in next patch where
I am about to defer request submission in the worker context if queue is
full.
This simplifies the code a bit.
Also add two helper functions to inc/dec in_flight. Decrement in_flight
helper will later used to call completion when in_flight reaches zero.
Signed-off-
FR_SENT flag should be set when request has been sent successfuly sent
over virtqueue. This is used by interrupt logic to figure out if interrupt
request should be sent or not.
Also add it to fqp->processing list after sending it successfully.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_f
ans requests are not completing, that
means descriptors are not being freed and that means submitter can't
make progress. Deadlock.
Fix this by punting the requests to a list and retry submission later
with the help of a worker.
Thanks
Vivek
Vivek Goyal (5):
virtiofs: Do not end request i
k)->rlock);
[ 603.140718] lock(&(>bg_lock)->rlock);
[ 603.140719]
[ 603.140719] *** DEADLOCK ***
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/virtio
s not get empty and submitter can't submit more requests.
To solve this issue, retry submission with the help of a worker, instead of
retrying in submitter's context. We already do this for hiprio/forget
requests.
Reported-by: Chirantan Ekbote
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_
about checking state of fpq->connected.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 24ac6f8bf3f7..3b7f7409e77b 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -960,
On Thu, Oct 03, 2019 at 10:42:44AM +0200, Miklos Szeredi wrote:
> On Wed, Oct 2, 2019 at 3:27 PM Vivek Goyal 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.
> &g
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 cleanup of retry logic. As of now we put
requests in a list and retry later with the help of a worker.
Other option will
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
On Sun, Sep 08, 2019 at 07:10:03PM +0800, piaojun wrote:
>
>
> On 2019/9/6 3:48, 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
On Fri, Sep 06, 2019 at 11:52:10AM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 05, 2019 at 03:48:49PM -0400, Vivek Goyal wrote:
> > +static void virtio_fs_drain_queue(struct virtio_fs_vq *fsvq)
> > +{
> > + WARN_ON(fsvq->in_flight < 0);
> > +
> > + /
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.
> >
>
On Fri, Sep 06, 2019 at 01:03:09PM +0100, Stefan Hajnoczi wrote:
> 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 de
On Fri, Sep 06, 2019 at 01:00:09PM +0100, Stefan Hajnoczi wrote:
> 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/
On Fri, Sep 06, 2019 at 01:52:41PM +0200, Miklos Szeredi wrote:
> On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi 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 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
---
fs/fuse/virtio_fs.c | 32 ++--
1 file
1 - 100 of 165 matches
Mail list logo
