From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52ECFD0E6C4 for ; Mon, 21 Oct 2024 17:01:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6B8A6B0089; Mon, 21 Oct 2024 13:01:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1B346B008A; Mon, 21 Oct 2024 13:01:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E3EB6B008C; Mon, 21 Oct 2024 13:01:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 80F016B0089 for ; Mon, 21 Oct 2024 13:01:50 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D25BE81AA8 for ; Mon, 21 Oct 2024 17:01:36 +0000 (UTC) X-FDA: 82698225918.30.A2A9185 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 69314C0013 for ; Mon, 21 Oct 2024 17:01:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HzbdOBNP; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf28.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729530071; a=rsa-sha256; cv=none; b=qiJsIR055L3aVM6KsTAfwWHD9P4calhjvLrMoQfe5esWIOq27zmaGB+1IlGAM+eHIQE7cF Y55UMHfLyWu1FGENmuO+2mZQAsmBlvhUy335eXJ6VpRP5KQTniNRW2wd0JQtliVmjgpiam k9eJ5QP6oRipqIBFQF4oW8F4j5s8E5o= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HzbdOBNP; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf28.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729530071; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qkyKip8HVy4uBOgJOwasMtM+gaqkeqOoz7QkU43yFDM=; b=PnxbAdsbNHPYloKDkKBHntEkgPEkWE4YZKlX7jcZkZ1AjqSgjEL5/mgHwM9ESOBbGj/fmj jRFGQ4L55xhBp+eiPT9rMGB3nYeuk+3wVBWdMuJlxgf2uYeW0cQc3mvK6KSXsKyxfXpwJI stuSSBhpWVOjNEUihIbodxT1ilBpgJI= Date: Mon, 21 Oct 2024 10:01:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729530106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qkyKip8HVy4uBOgJOwasMtM+gaqkeqOoz7QkU43yFDM=; b=HzbdOBNPkNqkKcMnxLjXRHP/eQCjnPme3CcqVlevQn1RY7kLGv3MEvJ3Gyy82YUPx0tUbh 2v9TRbmVvw8K209ILvW8ZwVTr1554Cs+Y6/BRpHvTv5zWlq40Fxby73TwaKUyHPdMtx7Ly JdLdR0mJJ/48AE/FJYMgShPmowDZFj0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Miklos Szeredi Cc: Joanne Koong , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, jefflexu@linux.alibaba.com, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: oqzkcb14qthbb1gwf6hki6qngsr378bn X-Rspamd-Queue-Id: 69314C0013 X-Rspamd-Server: rspam02 X-HE-Tag: 1729530093-950187 X-HE-Meta: U2FsdGVkX19LvcpcLkrLnNlh117h5G50XHesgWnq+wpzWuXeiAhNbiv5EtN9qBr3xtlrpHpjw/Fqjk6hZoo4GTfWwBB86lsh5NQT06ya8jEY8BOtY7Z6pM6FT6KGErIA7/SLxVARN7M1SMOTOPVs/iQTvohU0oDtKY6SJ+DiQu2Lp08E95/G+ZpzS6RoGMoB0BcsbE/0LCDPoFBEhYrO+fZ3UxwHjuftucx/AYtPyOBRjYMvUSWbgypwtug0Efa94fPcm/xxGk8jJ8BsCAZPFePJcX9TLuaCAwr1BaF6d96orWibveobkJV/SOzYjQpeppIKMOf0vjNcad4WhbnkOaZgfGNQb5TY1tIwDde4YK6akpEy+SX0VHz0k6qsst2YWxJF1IlSAX2QpcC1e+fRa36ztGAQt5UKLkW3g45NO3JKb0rCn86s/4sNx1DSZ/HK0HtnJVnvZOCvPwuw7zB7nh7lehaOl0znWRqxBknib+wsxXp373msyabR1slKsHMcymtVQJEPLIhBbsqC7+2nJSL1ly84F/soJJHVCZtHFBLPcWtIkRIdBJ5lD+Eysl7Ke8OYg8SKD/+01UFHMoXZusIKAkRUGnJw9RY9/YacyhCDLZbNmREh/nDLHVoQGXr3krTx+a1d9Uhd7cbYzA40UMytLJjrwYM2AFWXx7wtk/n8KGxG4SBabT14/lLIbq/u5WNttd1DggGkNvdwGq3NNSBK54uXg6Poh7wpWjRChLYhAMlri86ATYvHRYUbeXbHYmze3OVhJvUZIm6RSoaY4g/TewXLQw38Msx7phm5MQZlsIUyOZUzdIWSpdFBBF5XkeOX/piBzf07Sm9eOmqBQ94cUKZPRXHZpBD+GZ+hOwacuzboubNh5oqmNjE5bhzcrhd1CDq1XkeVvK+GCwYtzGMr9Dq5wRPBX+3pXmloMjIsRU6AL8yYfJ01UnJ3/pMRUuYTmeW54JzFgz1SFbT S2H77Del YHeTV81ggCZKLpaXqMPcJ+beh3q6zpsWfvYZwNlLl9aTVZjIdE/PCXXfydyAsccGZh02mFS/1b+98wnl8Cdli2m0mEWaZxQ7gKFeLOm/5JZlB7CrLF7kS/bvR3xWG6DwmyBW7nZdlX2egTmF04eebthtE9A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Oct 21, 2024 at 12:15:36PM GMT, Miklos Szeredi wrote: > On Fri, 18 Oct 2024 at 07:31, Shakeel Butt wrote: > > > I feel like this is too much restrictive and I am still not sure why > > blocking on fuse folios served by non-privileges fuse server is worse > > than blocking on folios served from the network. > > Might be. But historically fuse had this behavior and I'd be very > reluctant to change that unconditionally. > > With a systemwide maximal timeout for fuse requests it might make > sense to allow sync(2), etc. to wait for fuse writeback. > > Without a timeout allowing fuse servers to block sync(2) indefinitely > seems rather risky. > Thanks Miklos for the response. Just to be clear on where we disagree, let me point out what I think is right and please tell me where you disagree: 1. Fuse server should never access fuse folios (and files, directories, mounts, etc) directly it is providing. 2. Fuse server should not get blocked indirectly on the fuse folios (and related objects). This series is removing one such scenario caused due to reclaim. 3. Non fuse server processes can be blocked on fuse folios (and related objects) directly and indirectly. Am I understanding correctly that we disagree on (3)? thanks, Shakeel