Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp943278pxb; Fri, 22 Jan 2021 03:17:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwv0nGc9wrjwcyHaoZbcSM+6QlJCc1nQOikevKxHzjPZAC1DCzPi/F4P4RDmQJBpzLgMpyT X-Received: by 2002:a17:906:688c:: with SMTP id n12mr2803893ejr.111.1611314253299; Fri, 22 Jan 2021 03:17:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611314253; cv=none; d=google.com; s=arc-20160816; b=ByL6ytyCEEOs0Uwc7R7DmvzY/3affxd9UskTAA4UezkbkbU2iJ6MoSOxgEd14rhzAq IDH/uuvzKGHwlriuugFhEQJOB6ZvOjU+4fLEjw3N+EJkwQRod8coDSpVPrjoFRicRr4f SkvZ6Fto18p6TMkcUBGz+J0JsXq1QQRYHB3k8ajdANcDdjumJZkIXh+2cUAbVcAzdhn5 Rp290bEx00vHaoUTWgE07bRanjQ4fk6uugpeU/ccd+tSaZDJ9WkdFXA4JuMkoRnbZ0W0 buIPPqr1K0d1Jj7+C8CAKEq33dqI62+SgMvfspA06+n8TQobXd2bn9lvT5mxFtc5GMrx W5kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Gedglrbx9q6b8ayqlT6Zdi3perRe4tSg9LO4why35tI=; b=Wn03cLwsXuw+qUcaVM3YtAuLxSHFsRkLTxYgf5y7g/kdS68m+lcC5+mCyLZ+NZninN sgAIubguWRzyAUwfIk7pe36MqxCVFn+eSODVXtll+geYArVg/uB54+iwJa40jLpQotqr zCQnE5H2jRbolav2LH3D79QEkF9Yaqgu+1wSYnco0OHgBPAzwZqNKxVIrNZIHcwYD05f XIIgd0RKEmX1rDhXbg80dKs6+izI61NySIHyXTX7InVCuy4awSABJ6+riwWvOOHkaMxP TjMaVALQaGdOur5DbV8TE0wpWL0pIuU8/BwHffEg1CkzTHPNWkl9HokAUrW4ntKbcAJu G7AQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=UdfjlErG; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m25si3220207edr.186.2021.01.22.03.17.08; Fri, 22 Jan 2021 03:17:33 -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=pass header.i=@android.com header.s=20161025 header.b=UdfjlErG; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727664AbhAVLOC (ORCPT + 99 others); Fri, 22 Jan 2021 06:14:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727885AbhAVLHJ (ORCPT ); Fri, 22 Jan 2021 06:07:09 -0500 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C05EDC061786 for ; Fri, 22 Jan 2021 03:06:28 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id 7so4689370wrz.0 for ; Fri, 22 Jan 2021 03:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gedglrbx9q6b8ayqlT6Zdi3perRe4tSg9LO4why35tI=; b=UdfjlErGXEiKdZ1DUD/oqU/KTTdzQ35kaLmaXb2Aput23plO1PG2n8wz00QGwRxbfm v+e+CGIxZ9exmstKTQD+ThBW0YBP9qh0FqVTYGhd5U9E49K/o8GAAGtpTtVTc/CsYdjm 73QmE5wjKeT2rMyoHenk/Iw3RBWSGTFhDpvTF6j1MOKgdsVQZrb2KNKoLG69Ja8p6q1Y UuIve0YX00bAA1rkqqTZiUudX/LK/jKvSEYaD1RjA6isiunEv1SZf+21J7oICn5L92zX jxrJIbkKkVTiqeC97JYCVfrpDDJM2S/T0+sUdO3QhCgYjNz/+tbqfd8/eHyO1YZ+x9Dm Laug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Gedglrbx9q6b8ayqlT6Zdi3perRe4tSg9LO4why35tI=; b=EnTTMo0TtQcNPhG53koo9QyxJaDNkOFZEkojnqcjnzCBUzSSUBqLXPfxBGIZ1ewj1N WekdFU0/fIF3oUfIEN5hW4BszpGtRDXweb1SAKk+OZcLkLe6jz8tT0PpooxIhB1/RetM dPJob43NU+xlIdhLjnBEC6BuO/rfKVO9Oew7yZmaWRSb0JKdkjGQvytgRaXGcyTZDj/h EJn3UcuOMKDY2lCxmko8nd/zbq/v45fmd4dXfDYKDh+RQCzkAaoH2pe3PaBHHzYvvZLL Rt0Ij+wUWgffaW/nc5TTElekurwGPZf6DM59MTXZ+FuunR1stKMdxKsLy1fBCVK94zbL 0NKg== X-Gm-Message-State: AOAM530HV2v6WgMtR7ZCW29dHZRLwnJeSVOkbFMwou5l3cypV+rRqoDP YT8ljve6kNeZsvFgbf1waFrtug== X-Received: by 2002:a5d:44c6:: with SMTP id z6mr3958812wrr.306.1611313587592; Fri, 22 Jan 2021 03:06:27 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:8ce4:12a9:3261:aa54]) by smtp.gmail.com with ESMTPSA id z15sm11346881wrt.8.2021.01.22.03.06.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jan 2021 03:06:27 -0800 (PST) Date: Fri, 22 Jan 2021 11:06:25 +0000 From: Alessio Balsini To: Rokudo Yan Cc: balsini@android.com, akailash@google.com, amir73il@gmail.com, axboe@kernel.dk, bergwolf@gmail.com, duostefano93@gmail.com, dvander@google.com, fuse-devel@lists.sourceforge.net, gscrivan@redhat.com, jannh@google.com, kernel-team@android.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, maco@android.com, miklos@szeredi.hu, palmer@dabbelt.com, paullawrence@google.com, trapexit@spawn.link, zezeozue@google.com Subject: Re: [PATCH RESEND V11 0/7] fuse: Add support for passthrough read/write Message-ID: References: <20210118192748.584213-1-balsini@android.com> <20210119110654.11817-1-wu-yan@tcl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 19, 2021 at 12:34:23PM +0000, Alessio Balsini wrote: > On Tue, Jan 19, 2021 at 07:06:54PM +0800, Rokudo Yan wrote: > > on Mon, Jan 18, 2021 at 5:27 PM Alessio Balsini wrote: > > > > > > This is the 11th version of the series, rebased on top of v5.11-rc4. > > > Please find the changelog at the bottom of this cover letter. > > > > > > Add support for file system passthrough read/write of files when enabled > > > in userspace through the option FUSE_PASSTHROUGH. > > [...] > > > > > > Hi Allesio, > > > > Could you please add support for passthrough mmap too ? > > If the fuse file opened with passthrough actived, and then map (shared) to (another) process > > address space using mmap interface. As access the file with mmap will pass the vfs cache of fuse, > > but access the file with read/write will bypass the vfs cache of fuse, this may cause inconsistency. > > eg. the reader read the fuse file with mmap() and the writer modify the file with write(), the reader > > may not see the modification immediately since the writer bypass the vfs cache of fuse. > > Actually we have already meet an issue caused by the inconsistency after applying fuse passthrough > > scheme to our product. > > > > Thanks, > > yanwu. > > Hi yanwu, > > Thank you for your interest in this change. > > FUSE passthrough for mmap is an extension that is already in my TODO > list, together with passthrough for directories. > For now I would prefer to keep this series minimal to make the review > process leaner and simpler. > I will start working on extending this series with new features and > addressing more corner cases as soon as these changes get merged, what > do you think? > > Thanks, > Alessio Hi yanwu, Sorry if I overlooked this issue. I added memory-mapping to my tests and could reproduce/verify this wrong behavior you mentioned. I created this WIP (history may change) branch that has the missing mmap implementation: https://github.com/balsini/linux/commits/fuse-passthrough-v12-develop-v5.11-rc4 I did some mmap testing in the last days with this extra mmap implementation and couldn't find any issues, everything seems to be working as expected with the extra mmap patch. Can you please confirm this is fixed on your end too? I'm also going to revert in this branch the stacking policy changes to how they were in V10 as suggested by Amir if there are no concerns with that. I'm waiting for some extra tests to complete and, if no issue is detected, I'll post the V12 series super soon. Thanks, Alessio