Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6670389pxb; Wed, 17 Feb 2021 10:12:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3/ROFBSQzRHjl7A8AfugILV3Ds7Wz2XS7H3cRVwiWGx7UVl1rUYRHh5XXMMACTuoCMD6b X-Received: by 2002:a05:6402:5243:: with SMTP id t3mr55671edd.361.1613585526932; Wed, 17 Feb 2021 10:12:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613585526; cv=none; d=google.com; s=arc-20160816; b=RdhTdy5/NstuM6ydIF9hnTOzPKsWyHmpM+62772aB+acP8y7h27NzLZPbwml09xYOg Yoh8YUfc4fTXgemafbH4W2tYU8dAyFxr6vP2gkjqVOD/d61t4fqBUdk1gbm4lE7CDSKw I2KKDHI864j8g87f0Zr5ZUrGoF90hvzRVVflQlHqZWSE8TDCDlnp6+sB+8loGzxsSinq IldsUbpsDFksWcpoXOjrvZ/4RVpWkHIKui0HAZXCgWmFEdBEalI5I6QtlD77xT1Xhf0V WGMu3CsfeKpJrTzkWVWu9tUnr0pAA/JNJ/L4xyWvCAhsnIwq6juLquSileRtBzpYmJu6 0BbQ== 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=2BrS0+ssNbJaJ+JUXxaNPnqL/g3xkyb+nz2Bw22EZU0=; b=CNRh07Fapu0SXA2/f+uiYrvgT81rUvab3ep7c1xHXjnB7xd10Lrq7iI7CtpqNyAfHt b3yi9QY/G8WXF8pB+uUG5yY1sMkF3SSStakmeoV4Dvtlx5gn3TS50118bthz/Tt/f7aW dkj+DN/wMq91FterSWL0hG67Tf9Xrf+lzlbBaUvFIHOMhuT+GSpSdTk1BxrNtSUlp4DY yzaoDL3j2RreTMFEZPWuRmzv9A3KDPaJUlIi38Piw9P2iMeQIlhTK7tx3X9qaRkPQrpB qV5u/1fwqmCVf/svPjX07IdAvpztLKfck+m9PPpDcPtpZKKOnIp+Ra10Q/8sZ6pCrZLk 6Ftg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=dLLwCciD; 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 b2si1948195ejc.551.2021.02.17.10.11.41; Wed, 17 Feb 2021 10:12:06 -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=dLLwCciD; 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 S232869AbhBQOF7 (ORCPT + 99 others); Wed, 17 Feb 2021 09:05:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232683AbhBQOF7 (ORCPT ); Wed, 17 Feb 2021 09:05:59 -0500 Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2768C061574 for ; Wed, 17 Feb 2021 06:05:18 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id d13so518158vko.4 for ; Wed, 17 Feb 2021 06:05: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=2BrS0+ssNbJaJ+JUXxaNPnqL/g3xkyb+nz2Bw22EZU0=; b=dLLwCciDAgieVeCKNhmfIyOnK4x8JBF1YjzqcE1BwosEwGEJGA+vDKuP8fLkl5ek2Y xAx8x1cQFNXOO2JoiBvJsQh46wvYxkT3epAucH35ZYU46ld7TNa+JxCWCh7VfY7QMTME gTW1OFVJRd8Kx6fleDGiSQchqTXQnRKKShZUA= 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=2BrS0+ssNbJaJ+JUXxaNPnqL/g3xkyb+nz2Bw22EZU0=; b=HRXfhEyPbSkKYA3GQ8r9eqWiDNd8xAMNYGz9ljHH+S4aTbrUQlNYS2dWU3AbDol5zo l+iG9t3Tj+H9NzM9EvK2AlpA1m/OBaIezpAMVV/UeWZSuljR80nPK4ddvnUQAXudyEc5 jkEyFWu9rD+BKpHxT4d0NsOGTVXO856Zhxvv5vX9oso1WbyKlMFicqiMTmje8aqUys0L oBsJy92mg02dcH+CNsxY+WbJG5aaYn8KR/diVVXyU7QlrxcbYPaGA2E55QwmT4EUw/OF vXWlVPW0TGHnlhINDzwLSixhvQyXeRFloUrOCUSg8CJvpj1T0ppa6ZBhQtXgPccjkgtN CLwQ== X-Gm-Message-State: AOAM533i9+nzVfvIJfUy0NPVSExIjv7ij2r1eMPcvnN5LnD9Fhuvz8YR FdZx0dTnfk91uPT0MnIBNnkah8sFrtbowmQMSR5iXQ== X-Received: by 2002:a1f:c108:: with SMTP id r8mr14181633vkf.11.1613570717742; Wed, 17 Feb 2021 06:05:17 -0800 (PST) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-9-balsini@android.com> In-Reply-To: <20210125153057.3623715-9-balsini@android.com> From: Miklos Szeredi Date: Wed, 17 Feb 2021 15:05:07 +0100 Message-ID: Subject: Re: [PATCH RESEND V12 8/8] fuse: Introduce passthrough for mmap 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: > > Enabling FUSE passthrough for mmap-ed operations not only affects > performance, but has also been shown as mandatory for the correct > functioning of FUSE passthrough. > yanwu noticed [1] that a FUSE file with passthrough enabled may suffer > data inconsistencies if the same file is also accessed with mmap. What > happens is that read/write operations are directly applied to the lower > file system (and its cache), while mmap-ed operations are affecting the > FUSE cache. > > Extend the FUSE passthrough implementation to also handle memory-mapped > FUSE file, to both fix the cache inconsistencies and extend the > passthrough performance benefits to mmap-ed operations. > > [1] https://lore.kernel.org/lkml/20210119110654.11817-1-wu-yan@tcl.com/ > > Signed-off-by: Alessio Balsini > --- > fs/fuse/file.c | 3 +++ > fs/fuse/fuse_i.h | 1 + > fs/fuse/passthrough.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 45 insertions(+) > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > index cddada1e8bd9..e3741a94c1f9 100644 > --- a/fs/fuse/file.c > +++ b/fs/fuse/file.c > @@ -2370,6 +2370,9 @@ static int fuse_file_mmap(struct file *file, struct vm_area_struct *vma) > if (FUSE_IS_DAX(file_inode(file))) > return fuse_dax_mmap(file, vma); > > + if (ff->passthrough.filp) > + return fuse_passthrough_mmap(file, vma); > + > if (ff->open_flags & FOPEN_DIRECT_IO) { > /* Can't provide the coherency needed for MAP_SHARED */ > if (vma->vm_flags & VM_MAYSHARE) > diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h > index 815af1845b16..7b0d65984608 100644 > --- a/fs/fuse/fuse_i.h > +++ b/fs/fuse/fuse_i.h > @@ -1244,5 +1244,6 @@ int fuse_passthrough_setup(struct fuse_conn *fc, struct fuse_file *ff, > 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); > +ssize_t fuse_passthrough_mmap(struct file *file, struct vm_area_struct *vma); > > #endif /* _FS_FUSE_I_H */ > diff --git a/fs/fuse/passthrough.c b/fs/fuse/passthrough.c > index 24866c5fe7e2..284979f87747 100644 > --- a/fs/fuse/passthrough.c > +++ b/fs/fuse/passthrough.c > @@ -135,6 +135,47 @@ ssize_t fuse_passthrough_write_iter(struct kiocb *iocb_fuse, > return ret; > } > > +ssize_t fuse_passthrough_mmap(struct file *file, struct vm_area_struct *vma) > +{ > + int ret; > + const struct cred *old_cred; > + struct fuse_file *ff = file->private_data; > + struct inode *fuse_inode = file_inode(file); > + struct file *passthrough_filp = ff->passthrough.filp; > + struct inode *passthrough_inode = file_inode(passthrough_filp); > + > + if (!passthrough_filp->f_op->mmap) > + return -ENODEV; > + > + if (WARN_ON(file != vma->vm_file)) > + return -EIO; > + > + vma->vm_file = get_file(passthrough_filp); > + > + old_cred = override_creds(ff->passthrough.cred); > + ret = call_mmap(vma->vm_file, vma); > + revert_creds(old_cred); > + > + if (ret) > + fput(passthrough_filp); > + else > + fput(file); > + > + if (file->f_flags & O_NOATIME) > + return ret; > + > + if ((!timespec64_equal(&fuse_inode->i_mtime, > + &passthrough_inode->i_mtime) || > + !timespec64_equal(&fuse_inode->i_ctime, > + &passthrough_inode->i_ctime))) { > + fuse_inode->i_mtime = passthrough_inode->i_mtime; > + fuse_inode->i_ctime = passthrough_inode->i_ctime; Again, violation of rules. Not sure why this is needed, mmap(2) isn't supposed to change mtime or ctime, AFAIK. Thanks, Miklos