Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1396134pxj; Fri, 21 May 2021 13:12:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyMviTzDvFrmVE3omMlR6gjkVUb6OzCgcV9h/9w69eQ+myLAKNCxvui2kZ30xH7W2JcWJc X-Received: by 2002:a05:6638:635:: with SMTP id h21mr6753623jar.135.1621627948109; Fri, 21 May 2021 13:12:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621627948; cv=none; d=google.com; s=arc-20160816; b=KWRK8eKKXqAIsT1Ho7fCBkrlB35JWtrHpdfxho0H25V80LBNBS9gZQZ0rhJ37La9O5 09rBIubOfoVdqHxY93e3xOYTbY7TmEUHIY52A6TDJex9HInQaACGPMsu7VTdgPYnPm6Q WevyDHNKFzxTdPXkrJQNE+JBB0jnHI1+4noVJsp2fvWpGG4uMXhDdv8NUXVmoz91qAKA AlgdyNDTgBhyrvT1XnEdmSPg2YyTBiA1fPofYDvKMXg+kTps6jJeTEh9pu2645LZc96q qnBXSLs/s6kcf+IsJ4WoCHrkRmy8jKVHrzvdTHcnbeeAhr3AE/+i3NyDiLvVigjyOFOX QZOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=+21u3N72w93fvXrJyYJRHMgu+/V0tMXM4n7rNf+xir4=; b=Hn1IP1X26BMA+n5mXql0YB8FbbtQGLdw9Gr8EVvFRFTdODvUZHtIzwnK0p0ndcsQET o2V2WQ20LIwcaS3tN6dO39txCAOf13t6S6na4JS8PZFUEj9LpPKrRH4lXROq+KwSQZpq xDIoT2ECGMGPngjqls/nc1+UUjg6aCHuDIYGh9bqSSl9L3WF0IwEP9zhr0Md0cSu0lku /DDuFA0ic80TgZiTJDo+WJdq2ceC2HM9Yxgag29CvIwdBjID14B1rKoVsrs6TpEKqxxt i5O1iZH7vOOX8dOJx53NebUwCWYa3scKfzQAMC4Ha40nFtttB4EOys9FSgcgno/NxxYk FWOQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l22si6938196jad.10.2021.05.21.13.12.15; Fri, 21 May 2021 13:12:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232213AbhEUKKW convert rfc822-to-8bit (ORCPT + 99 others); Fri, 21 May 2021 06:10:22 -0400 Received: from us-smtp-delivery-44.mimecast.com ([207.211.30.44]:39935 "EHLO us-smtp-delivery-44.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231735AbhEUKKV (ORCPT ); Fri, 21 May 2021 06:10:21 -0400 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-385-iY0fUjhYN9WKYHifbwWMXg-1; Fri, 21 May 2021 06:08:56 -0400 X-MC-Unique: iY0fUjhYN9WKYHifbwWMXg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0720D801B14; Fri, 21 May 2021 10:08:55 +0000 (UTC) Received: from bahia.lan (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 28463608DB; Fri, 21 May 2021 10:08:42 +0000 (UTC) Date: Fri, 21 May 2021 12:08:40 +0200 From: Greg Kurz To: Miklos Szeredi Cc: , , , , Stefan Hajnoczi , Max Reitz , Vivek Goyal , Robert Krawitz Subject: Re: [PATCH v4 5/5] virtiofs: propagate sync() to file server Message-ID: <20210521120840.4658d42c@bahia.lan> In-Reply-To: <20210520154654.1791183-6-groug@kaod.org> References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-6-groug@kaod.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kaod.org Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 May 2021 17:46:54 +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 returns right away even though > data still needs to be flushed from the host page cache. > > This is easily demonstrated by doing the following in the guest: > > $ dd if=/dev/zero of=/mnt/foo bs=1M count=5K ; strace -T -e sync sync > 5120+0 records in > 5120+0 records out > 5368709120 bytes (5.4 GB, 5.0 GiB) copied, 5.22224 s, 1.0 GB/s > sync() = 0 <0.024068> > +++ exited with 0 +++ > > and start the following in the host when the 'dd' command completes > in the guest: > > $ strace -T -e fsync /usr/bin/sync virtiofs/foo > fsync(3) = 0 <10.371640> > +++ exited with 0 +++ > > There are no good reasons not to honor the expected behavior of > sync() actually : it gives an unrealistic impression that virtiofs > is super fast and that data has safely landed on HW, which isn't > the case obviously. > > Implement a ->sync_fs() superblock operation that sends a new > FUSE_SYNCFS request type for this purpose. Provision a 64-bit > placeholder for possible future extensions. Since the file > server cannot handle the wait == 0 case, we skip it to avoid a > gratuitous roundtrip. Note that this is per-superblock : a > FUSE_SYNCFS is send for the root mount and for each submount. > s/send/sent Miklos, Great thanks for the quick feedback on these patches ! :) Apart from the fact that nothing is sent for submounts as long as we don't set SB_BORN on them, this patch doesn't really depends on the previous ones. If it looks good to you, maybe you can just merge it and I'll re-post the fixes separately ? Cheers, -- Greg > Like with FUSE_FSYNC and FUSE_FSYNCDIR, lack of support for > FUSE_SYNCFS in the file server is treated as permanent success. > This ensures compatibility with older file servers : the client > will get the current behavior of sync() not being propagated to > the file server. > > Note that such an operation allows the file server to DoS sync(). > Since a typical FUSE file server is an untrusted piece of software > running in userspace, this is disabled by default. Only enable it > with virtiofs for now since virtiofsd is supposedly trusted by the > guest kernel. > > Reported-by: Robert Krawitz > Signed-off-by: Greg Kurz > --- > fs/fuse/fuse_i.h | 3 +++ > fs/fuse/inode.c | 40 +++++++++++++++++++++++++++++++++++++++ > fs/fuse/virtio_fs.c | 1 + > include/uapi/linux/fuse.h | 10 +++++++++- > 4 files changed, 53 insertions(+), 1 deletion(-) > > diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h > index e2f5c8617e0d..01d9283261af 100644 > --- a/fs/fuse/fuse_i.h > +++ b/fs/fuse/fuse_i.h > @@ -761,6 +761,9 @@ struct fuse_conn { > /* Auto-mount submounts announced by the server */ > unsigned int auto_submounts:1; > > + /* Propagate syncfs() to server */ > + unsigned int sync_fs:1; > + > /** The number of requests waiting for completion */ > atomic_t num_waiting; > > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c > index 123b53d1c3c6..96b00253f766 100644 > --- a/fs/fuse/inode.c > +++ b/fs/fuse/inode.c > @@ -506,6 +506,45 @@ static int fuse_statfs(struct dentry *dentry, struct kstatfs *buf) > return err; > } > > +static int fuse_sync_fs(struct super_block *sb, int wait) > +{ > + struct fuse_mount *fm = get_fuse_mount_super(sb); > + struct fuse_conn *fc = fm->fc; > + struct fuse_syncfs_in inarg; > + FUSE_ARGS(args); > + int err; > + > + /* > + * Userspace cannot handle the wait == 0 case. Avoid a > + * gratuitous roundtrip. > + */ > + if (!wait) > + return 0; > + > + /* The filesystem is being unmounted. Nothing to do. */ > + if (!sb->s_root) > + return 0; > + > + if (!fc->sync_fs) > + return 0; > + > + memset(&inarg, 0, sizeof(inarg)); > + args.in_numargs = 1; > + args.in_args[0].size = sizeof(inarg); > + args.in_args[0].value = &inarg; > + args.opcode = FUSE_SYNCFS; > + args.nodeid = get_node_id(sb->s_root->d_inode); > + args.out_numargs = 0; > + > + err = fuse_simple_request(fm, &args); > + if (err == -ENOSYS) { > + fc->sync_fs = 0; > + err = 0; > + } > + > + return err; > +} > + > enum { > OPT_SOURCE, > OPT_SUBTYPE, > @@ -909,6 +948,7 @@ static const struct super_operations fuse_super_operations = { > .put_super = fuse_put_super, > .umount_begin = fuse_umount_begin, > .statfs = fuse_statfs, > + .sync_fs = fuse_sync_fs, > .show_options = fuse_show_options, > }; > > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > index 8962cd033016..f649a47efb68 100644 > --- a/fs/fuse/virtio_fs.c > +++ b/fs/fuse/virtio_fs.c > @@ -1455,6 +1455,7 @@ static int virtio_fs_get_tree(struct fs_context *fsc) > fc->release = fuse_free_conn; > fc->delete_stale = true; > fc->auto_submounts = true; > + fc->sync_fs = true; > > /* Tell FUSE to split requests that exceed the virtqueue's size */ > fc->max_pages_limit = min_t(unsigned int, fc->max_pages_limit, > diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h > index 271ae90a9bb7..36ed092227fa 100644 > --- a/include/uapi/linux/fuse.h > +++ b/include/uapi/linux/fuse.h > @@ -181,6 +181,9 @@ > * - add FUSE_OPEN_KILL_SUIDGID > * - extend fuse_setxattr_in, add FUSE_SETXATTR_EXT > * - add FUSE_SETXATTR_ACL_KILL_SGID > + * > + * 7.34 > + * - add FUSE_SYNCFS > */ > > #ifndef _LINUX_FUSE_H > @@ -216,7 +219,7 @@ > #define FUSE_KERNEL_VERSION 7 > > /** Minor version number of this interface */ > -#define FUSE_KERNEL_MINOR_VERSION 33 > +#define FUSE_KERNEL_MINOR_VERSION 34 > > /** The node ID of the root inode */ > #define FUSE_ROOT_ID 1 > @@ -509,6 +512,7 @@ enum fuse_opcode { > FUSE_COPY_FILE_RANGE = 47, > FUSE_SETUPMAPPING = 48, > FUSE_REMOVEMAPPING = 49, > + FUSE_SYNCFS = 50, > > /* CUSE specific operations */ > CUSE_INIT = 4096, > @@ -971,4 +975,8 @@ struct fuse_removemapping_one { > #define FUSE_REMOVEMAPPING_MAX_ENTRY \ > (PAGE_SIZE / sizeof(struct fuse_removemapping_one)) > > +struct fuse_syncfs_in { > + uint64_t padding; > +}; > + > #endif /* _LINUX_FUSE_H */