> Subject: [PATCH 1/1] virtiofsd: Allow to build it without the tools
>
> This changed the Meson build script to allow virtiofsd be built even
> though the tools build is disabled, thus honoring the --enable-virtiofsd
> option.
>
> Signed-off-by: Wainer dos Santos Moschetta
I misunderstood that
...
> > BTW, while testing the updated patch, I noticed current master branch (as
> > of 10/08) fails to execute virtiofsd.
> > backtrace from coredump shows:
> > #0 get_relocated_path (dir=0x560f4d2f2ef0
> > "/usr/local/var/run/virtiofsd") at ../util/cutils.c:924
> > #1 0x560f4baab6da in qe
> On 07/10/20 11:29, Misono Tomohiro wrote:
> > Currently it is unknown whether virtiofsd will be built at
> > configuration time. It will be automatically built when dependency is
> > met. Also, required libraries are not clear.
> >
> > To make this clear, add configure option --{enable,disable}-v
> Right now we enable remote posix locks by default. That means when guest does
> a posix lock it sends request to server
> (virtiofsd). But currently we only support non-blocking posix lock and return
> -EOPNOTSUPP for blocking version.
>
> This means that existing applications which are doing
> Subject: [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error
>
> An assertion failure is raised during request processing if
> unshare(CLONE_FS) fails. Implement a probe at startup so the problem can
> be detected right away.
>
> Unfortunately Docker/Moby does not include unsha
> > On Thu, Jan 16, 2020 at 09:25:42PM +0900, Misono Tomohiro wrote:
> > > > From: Stefan Hajnoczi
> > > >
> > > > If thread A is using an inode it must not be deleted by thread B
> > > > when processing a FUSE_FORGET request.
> > > >
> > > > The FUSE protocol itself already has a counter called n
> * Misono Tomohiro (misono.tomoh...@jp.fujitsu.com) wrote:
> > > From: Liu Bo
> > >
> > > For fuse's queueinfo, both queueinfo array and queueinfos are
> > > allocated in
> > > fv_queue_set_started() but not cleaned up when the daemon process quits.
> > >
> > > This fixes the leak in proper place
> > -Original Message-
> > From: virtio-fs-boun...@redhat.com
> > [mailto:virtio-fs-boun...@redhat.com] On Behalf Of
> > misono.tomoh...@fujitsu.com
> > Sent: Friday, October 25, 2019 7:02 PM
> > To: 'Vivek Goyal'
> > Cc: virtio.
> -Original Message-
> From: virtio-fs-boun...@redhat.com [mailto:virtio-fs-boun...@redhat.com] On
> Behalf Of misono.tomoh...@fujitsu.com
> Sent: Friday, October 25, 2019 7:02 PM
> To: 'Vivek Goyal'
> Cc: virtio...@redhat.com; qemu-devel@nongnu.org
>
> On Wed, Oct 23, 2019 at 04:07:52PM -0400, Vivek Goyal wrote:
> > On Wed, Oct 23, 2019 at 09:25:23PM +0900, Misono Tomohiro wrote:
> > > When writeback mode is enabled (-o writeback), O_APPEND handling is
> > > done in kernel. Therefore virtiofsd clears O_APPEND flag when open.
> > > Otherwise O_A
2] virtiofsd: Two fix for xattr operation
>
> On Fri, Oct 18, 2019 at 08:51:20AM +, misono.tomoh...@fujitsu.com wrote:
> > > Doing unshare(CLONE_FS) after thread startup seems safe, though must
> > > be careful to change the working directory to the root of the mount
>
> > Even simpler: allow O_PATH descriptors for f*xattr().
>
> Attached patch. Will post shortly.
>
> However, I think it would make sense to fix virtiofsd as well, as this will
> take time to percolate down, even if Al doesn't find
> anything wrong with it.
Thanks for you comments.
Though I'm
12 matches
Mail list logo
