Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6668676pxb; Wed, 17 Feb 2021 10:09:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOqYyEVklZMylnR9Pv+7IdS6V4cOcyAbRfcw7SqXua0csw8dR6jvhBeLRyJBvkazQ0a+EG X-Received: by 2002:a17:906:948c:: with SMTP id t12mr169626ejx.259.1613585380344; Wed, 17 Feb 2021 10:09:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613585380; cv=none; d=google.com; s=arc-20160816; b=DT5V0cqdZrh35x3gexkzwuZ1EVxyYINBesmaf48B40BjfgU0pqHQVK6GGE685/wu8V 3+PCKehHHKRKdnj7nuIJ1E9048tawY+ZU5hNpyvJHoUl4pln1Q2dkU7LkA7XuXzpinUk zj392Plgvgu/4xI6hG0mWtwGn4QAqfTsZdriyfjJ5GGO74DXT+/BKvnnutV0AwPwQjnY o5+nXnZ3EsKcENuIwl1YkEXiSO/aqhAwRPfCsdfS8Kl560SA0qxY5eXK1wDuadk823Fj pTXWJ/GmIrUZzkp/dmvt4C4fCEqRjOFzjDCs8udrmPlSX67ou4BpvGQM0tpP1BTMEP2T oW1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=mUiZCwMmsWsrhaAe2fPZND6ofvBT8klJLiYwu6OuvSQ=; b=NGL2EmHFDykGALOKnbo80VATplRimxRk7eMeQe2XQ5w1ROsUQuCFQ4zA5J+/Q0XikH tWHq2Aj6O4Y2BdeQLsQQm2YVOFHGslhss1xTa/BpuUDdNBfN6HuifBjcW6my/UDFvvEd 9bBwBnbRjVYC+QUDw+d+pWvg1k+K8QqP2kDRTayLDcjOa+dd7bf6tiCOVWcOqFRT6zom 8WQqHQRDtXWCL+yW+LZgwOBYblsg2CKBgikl08h6Ws5m22eOzshUdj1FiRM2HSMWKHr7 91Wa/PDfCZfFOuHf00Uc0PC03iEnAAi8FY17F/1kLUbnTJDIQAR0YKoThnd0NoeyH2vE 0Qfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=LLs6QXry; 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 p24si1847310edw.475.2021.02.17.10.09.16; Wed, 17 Feb 2021 10:09:40 -0800 (PST) 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; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=LLs6QXry; 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 S233203AbhBQOBC (ORCPT + 99 others); Wed, 17 Feb 2021 09:01:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232841AbhBQOA6 (ORCPT ); Wed, 17 Feb 2021 09:00:58 -0500 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8789FC061756 for ; Wed, 17 Feb 2021 06:00:18 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id a62so3474493vsa.10 for ; Wed, 17 Feb 2021 06:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mUiZCwMmsWsrhaAe2fPZND6ofvBT8klJLiYwu6OuvSQ=; b=LLs6QXryF5u6+AxYq5B0es7Kss78Bqzk0m8UEQAEvVpAnHAsldDfCQBM9cpP28ex2m SN1XOgbZElUQjqfgDsbCv0xV9gUcWMBDsKFbMq9J/zscqgF73jadReNdIooV1Fw/Ds7H BLShsw3Lp77h7PYOPm0Qk0JDpBwXgXj6mWiGo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mUiZCwMmsWsrhaAe2fPZND6ofvBT8klJLiYwu6OuvSQ=; b=UAwkUjt5hSE2bg8LuJhTV8xhzf9PUFAnJHEgH+AbHmuYp65EXe9ANI6m9MvF8O5s+u 722WNubeZyUfzQVGtrnoZllq8KJ+8X0ZrewxzIgNqmtPw6jPyE2tPxNxLBu1r/LsqQFA 3SYzqZ/9yXvL/enCqJWWYhccMypj4uEdmBwL5V7MAePcSnLtZ6cbCuCzhx938O0sr5K5 L+vFiYMZuAanqlOqZdrYt9TL5dWLUYFeKMUTjOHiMVrr2BT5quL7zI4HhMcfyx2AJXF9 r9ZAEz71pKOQqIzJpRNoxYRfRnakMB+mpphAo1YLQLd2j3cHge0gxC1toHX8ZS86GENw 1pWg== X-Gm-Message-State: AOAM531mhwYxWYnpLuH1lM5akIrrGZGK+/4kndNQjzOwrzLOEkLM0kul fn7SPMgbUYOe/rQzhkmk/b9Lv0bVPn8Q+Dhv/9VkJg== X-Received: by 2002:a67:8844:: with SMTP id k65mr1266666vsd.9.1613570417388; Wed, 17 Feb 2021 06:00:17 -0800 (PST) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-6-balsini@android.com> In-Reply-To: <20210125153057.3623715-6-balsini@android.com> From: Miklos Szeredi Date: Wed, 17 Feb 2021 15:00:06 +0100 Message-ID: Subject: Re: [PATCH RESEND V12 5/8] fuse: Introduce synchronous read and write for passthrough To: Alessio Balsini Cc: Akilesh Kailash , Amir Goldstein , Antonio SJ Musumeci , David Anderson , Giuseppe Scrivano , Jann Horn , Jens Axboe , Martijn Coenen , Palmer Dabbelt , Paul Lawrence , Peng Tao , Stefano Duo , Zimuzo Ezeozue , wuyan , fuse-devel , kernel-team , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2021 at 4:31 PM Alessio Balsini wrote: > > All the read and write operations performed on fuse_files which have the > passthrough feature enabled are forwarded to the associated lower file > system file via VFS. > > Sending the request directly to the lower file system avoids the > userspace round-trip that, because of possible context switches and > additional operations might reduce the overall performance, especially > in those cases where caching doesn't help, for example in reads at > random offsets. > > Verifying if a fuse_file has a lower file system file associated with > can be done by checking the validity of its passthrough_filp pointer. > This pointer is not NULL only if passthrough has been successfully > enabled via the appropriate ioctl(). > When a read/write operation is requested for a FUSE file with > passthrough enabled, a new equivalent VFS request is generated, which > instead targets the lower file system file. > The VFS layer performs additional checks that allow for safer operations > but may cause the operation to fail if the process accessing the FUSE > file system does not have access to the lower file system. > > This change only implements synchronous requests in passthrough, > returning an error in the case of asynchronous operations, yet covering > the majority of the use cases. > > Signed-off-by: Alessio Balsini > --- > fs/fuse/file.c | 8 ++++-- > fs/fuse/fuse_i.h | 2 ++ > fs/fuse/passthrough.c | 57 +++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 65 insertions(+), 2 deletions(-) > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > index 953f3034c375..cddada1e8bd9 100644 > --- a/fs/fuse/file.c > +++ b/fs/fuse/file.c > @@ -1581,7 +1581,9 @@ static ssize_t fuse_file_read_iter(struct kiocb *iocb, struct iov_iter *to) > if (FUSE_IS_DAX(inode)) > return fuse_dax_read_iter(iocb, to); > > - if (!(ff->open_flags & FOPEN_DIRECT_IO)) > + if (ff->passthrough.filp) > + return fuse_passthrough_read_iter(iocb, to); > + else if (!(ff->open_flags & FOPEN_DIRECT_IO)) > return fuse_cache_read_iter(iocb, to); > else > return fuse_direct_read_iter(iocb, to); > @@ -1599,7 +1601,9 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb, struct iov_iter *from) > if (FUSE_IS_DAX(inode)) > return fuse_dax_write_iter(iocb, from); > > - if (!(ff->open_flags & FOPEN_DIRECT_IO)) > + if (ff->passthrough.filp) > + return fuse_passthrough_write_iter(iocb, from); > + else if (!(ff->open_flags & FOPEN_DIRECT_IO)) > return fuse_cache_write_iter(iocb, from); > else > return fuse_direct_write_iter(iocb, from); > diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h > index 8d39f5304a11..c4730d893324 100644 > --- a/fs/fuse/fuse_i.h > +++ b/fs/fuse/fuse_i.h > @@ -1239,5 +1239,7 @@ int fuse_passthrough_open(struct fuse_dev *fud, > int fuse_passthrough_setup(struct fuse_conn *fc, struct fuse_file *ff, > struct fuse_open_out *openarg); > void fuse_passthrough_release(struct fuse_passthrough *passthrough); > +ssize_t fuse_passthrough_read_iter(struct kiocb *iocb, struct iov_iter *to); > +ssize_t fuse_passthrough_write_iter(struct kiocb *iocb, struct iov_iter *from); > > #endif /* _FS_FUSE_I_H */ > diff --git a/fs/fuse/passthrough.c b/fs/fuse/passthrough.c > index cf993e83803e..d949ca07a83b 100644 > --- a/fs/fuse/passthrough.c > +++ b/fs/fuse/passthrough.c > @@ -4,6 +4,63 @@ > > #include > #include > +#include > + > +#define PASSTHROUGH_IOCB_MASK \ > + (IOCB_APPEND | IOCB_DSYNC | IOCB_HIPRI | IOCB_NOWAIT | IOCB_SYNC) > + > +static void fuse_copyattr(struct file *dst_file, struct file *src_file) > +{ > + struct inode *dst = file_inode(dst_file); > + struct inode *src = file_inode(src_file); > + > + i_size_write(dst, i_size_read(src)); > +} Hmm, I see why this is done, yet it's contrary to what's been set out at the beginning: "All the requests other than reads or writes are still handled by the userspace FUSE daemon." Maybe just use fuse_write_update_size() instead of copying the size from the underlying inode. > + > +ssize_t fuse_passthrough_read_iter(struct kiocb *iocb_fuse, > + struct iov_iter *iter) > +{ > + ssize_t ret; > + struct file *fuse_filp = iocb_fuse->ki_filp; > + struct fuse_file *ff = fuse_filp->private_data; > + struct file *passthrough_filp = ff->passthrough.filp; > + > + if (!iov_iter_count(iter)) > + return 0; > + > + ret = vfs_iter_read(passthrough_filp, iter, &iocb_fuse->ki_pos, > + iocb_to_rw_flags(iocb_fuse->ki_flags, > + PASSTHROUGH_IOCB_MASK)); Please split this line up into: rwf = ioctb_to_rw_flags(...); ret = vfs_iter_read(..., rwf); > + > + return ret; > +} > + > +ssize_t fuse_passthrough_write_iter(struct kiocb *iocb_fuse, > + struct iov_iter *iter) > +{ > + ssize_t ret; > + struct file *fuse_filp = iocb_fuse->ki_filp; > + struct fuse_file *ff = fuse_filp->private_data; > + struct inode *fuse_inode = file_inode(fuse_filp); > + struct file *passthrough_filp = ff->passthrough.filp; > + > + if (!iov_iter_count(iter)) > + return 0; > + > + inode_lock(fuse_inode); > + > + file_start_write(passthrough_filp); > + ret = vfs_iter_write(passthrough_filp, iter, &iocb_fuse->ki_pos, > + iocb_to_rw_flags(iocb_fuse->ki_flags, > + PASSTHROUGH_IOCB_MASK)); Same here. Thanks, Miklos