From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fastmail.fm header.i=@fastmail.fm header.b="nuRtmPSn"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="h+lf17fR" Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B73E10C3 for ; Thu, 7 Dec 2023 00:56:23 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 780B35C01DA; Thu, 7 Dec 2023 03:56:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 07 Dec 2023 03:56:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1701939380; x=1702025780; bh=PkOQFYOrwAv5+bw6+i9x6WT4/rCNJ/rW2TV uc2i5Zq0=; b=nuRtmPSnXWfZ4+KJGjni0Q7wUg7mAxUrGDD80kgmnwAPxy3sIcS DY89ThFVpDUdlXZkLq2OdDKQDOEJ26u2R5yitqWQjF94jEzxBJDC4jo3B+HWAe9g dQrkVtqXV9xqPVnr1M51RuJwHWPz/9jI6b91rZkE1gMJyf1bvZKZMB0qVe74VP3g FeMRgYvpfqT4bYmN7IpJAO8di4WAg/wh5T8/nSJ3cgk9iOODzZ77TUcKbWhnSwHw OlqUK9udXUGXGrQFpCQ9qIl7E0eMEyR61BVOUZVEhkgUHhcZVg6Y+Fu62Nkb5mXI gFiFIOTqbGTGtjiSsf+PI1Cw7042LCMCtdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1701939380; x=1702025780; bh=PkOQFYOrwAv5+bw6+i9x6WT4/rCNJ/rW2TV uc2i5Zq0=; b=h+lf17fR1J2PjtPcg5nKcPJq9uGmcbpSiWwfNpQDVWAD+LsGUke Wv9XKdfIu4SJGXN3UNOClbQQRsEQcA72f5MmpaEZmAb+BZPClHsLVcWhW0v0nbvy YdLEeAk14SfohfnhFzRSEGd5zuJqODy/VuHmuDq0w1AEw+i7aG3X8a/t+3X7/POW V+B0ey6iCaGvXcwY49RD0fnRmapPTysP+DoaLL9gIIPqHHCkeuqdAyDO2uhYGrwE ayzUdAya6T+IE3gVe+X0KiX/l3pWE7XPatXNcjGnVTIjX2nEg3PbATGo7q0p2Kos 1tuMAbl/wS+zyxRu4oNEiUQFfY1neqC+a2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudekuddguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepuegv rhhnugcuufgthhhusggvrhhtuceosggvrhhnugdrshgthhhusggvrhhtsehfrghsthhmrg hilhdrfhhmqeenucggtffrrghtthgvrhhnpeduleefvdduveduveelgeelffffkedukeeg veelgfekleeuvdehkeehheehkefhfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegsvghrnhgurdhstghhuhgsvghrthesfhgrshhtmhgrihhl rdhfmh X-ME-Proxy: Feedback-ID: id8a24192:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Dec 2023 03:56:18 -0500 (EST) Message-ID: <89bf04b5-fefb-415a-942b-a4e1dc18a62a@fastmail.fm> Date: Thu, 7 Dec 2023 09:56:15 +0100 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 00/12] FUSE passthrough for file io To: Amir Goldstein Cc: Miklos Szeredi , Daniel Rosenberg , Paul Lawrence , Alessio Balsini , Christian Brauner , fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Dave Chinner References: <20231016160902.2316986-1-amir73il@gmail.com> Content-Language: en-US, de-DE From: Bernd Schubert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/7/23 08:23, Amir Goldstein wrote: > On Thu, Dec 7, 2023 at 1:11 AM Bernd Schubert > wrote: >> >> Hi Amir, >> >> >> On 12/6/23 10:59, Amir Goldstein wrote: >>> On Wed, Nov 29, 2023 at 6:55 PM Miklos Szeredi wrote: >>>> >>>> On Wed, 29 Nov 2023 at 16:52, Amir Goldstein wrote: >>>> >>>>> direct I/O read()/write() is never a problem. >>>>> >>>>> The question is whether mmap() on a file opened with FOPEN_DIRECT_IO >>>>> when the inode is in passthrough mode, also uses fuse_passthrough_mmap()? >>>> >>>> I think it should. >>>> >>>>> or denied, similar to how mmap with ff->open_flags & FOPEN_DIRECT_IO && >>>>> vma->vm_flags & VM_MAYSHARE) && !fc->direct_io_relax >>>>> is denied? >>>> >>>> What would be the use case for FOPEN_DIRECT_IO with passthrough mmap? >>>> >>>>> A bit more challenging, because we will need to track unmounts, or at >>>>> least track >>>>> "was_cached_mmaped" state per file, but doable. >>>> >>>> Tracking unmaps via fuse_vma_close() should not be difficult. >>>> >>> >>> I think that it is. >>> >>> fuse_vma_close() does not seem to be balanced with fuse_file_mmap() >>> because IIUC, maps can be cloned via fork() etc. >>> >>> It tried to implement an iocachectr refcount to track cache mmaps, >>> but it keeps underflowing in fuse_vma_close(). >>> >>> I would like us to consider a slightly different model. >>> >>> We agreed that caching and passthrough mode on the same >>> inode cannot mix and there is no problem with different modes >>> per inode on the same filesystem. >>> >>> I have a use case for mixing direct_io and passthrough on the >>> same inode (i.e. inode in passthrough mode). >>> >>> I have no use case (yet) for the transition from caching to passthrough >>> mode on the same inode and direct_io cached mmaps complicate >>> things quite a bit for this scenario. >>> >>> My proposal is to taint a direct_io file with FOPEN_CACHE_MMAP >>> if it was ever mmaped using page cache. >>> We will not try to clean this flag in fuse_vma_close(), it stays with >>> the file until release. >>> >>> An FOPEN_CACHE_MMAP file forces an inode into caching mode, >>> same as a regular caching open. >> >> where do you actually want to set that flag? My initial idea for >> FUSE_I_CACHE_WRITES was to set that in fuse_file_mmap, but I would have >> needed the i_rwsem lock and that resulted in a lock ordering issue. >> > > Yes, the idea is to set this flag on the first mmap of a FOPEN_DIRECT_IO file. > Why does that require an i_rwsem lock? > > Before setting FUSE_I_CACHE_WRITES inode flag, your patch does: > wait_event(fi->direct_io_waitq, fi->shared_lock_direct_io_ctr == 0); > > We can do the same in direct_io mmap, before setting the > FOPEN_CACHE_MMAP file flag and consequently changing inode > mode to caching. No? Yeah right, that will work. Thanks, Bernd