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 80310C36002 for ; Wed, 9 Apr 2025 22:05:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1FC16B027F; Wed, 9 Apr 2025 18:05:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCA186B0280; Wed, 9 Apr 2025 18:05:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB9E06B0281; Wed, 9 Apr 2025 18:05:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AEEF86B027F for ; Wed, 9 Apr 2025 18:05:27 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 110AD120EB2 for ; Wed, 9 Apr 2025 22:05:28 +0000 (UTC) X-FDA: 83315887536.23.0FBBE69 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf15.hostedemail.com (Postfix) with ESMTP id 3AC9DA001A for ; Wed, 9 Apr 2025 22:05:25 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hInql5Zl; spf=pass (imf15.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744236326; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=09r/CWT/cCwyNMYQClu5zBH5raBe8xtET0pxWWB2fIM=; b=Kh+ndtrWKr3KZLQ1udSQgky95nuryC76eL/tNDa0m4UH7ay0djK6Etg8jnm5t3XS/VtGoE 7wYdzTc6bRKgbwAoWdrpA2L0+ZBFY13n+PSpDt3riNh5SO0k3YEcTa0+FM1jpb9rqGp/5r G3xJq7HTjSmJspCido/+kDhnJPKTG38= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744236326; a=rsa-sha256; cv=none; b=8o6euOrCnoA9NwNbspzpwaYfy6DhOWT2yOroTB92cz51tyLnGTs4rIJHvz2I27ZyU0savl qSUIg/ODwsfeK19RVtZCbmHDRirHxB0RRnXstBWw7cx0b0wlDdup3jKwJLLrnCmXZc0rQk gez6jmL8q8NsBL842aUkKoHeA0MQwTo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hInql5Zl; spf=pass (imf15.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 9 Apr 2025 15:05:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1744236323; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=09r/CWT/cCwyNMYQClu5zBH5raBe8xtET0pxWWB2fIM=; b=hInql5ZlgGMEBjah698hzr352Uv7S/lOqlrEqZVxPqk/5PmtUoV+tAACFFc9f3SSn5wIFl VwdVSMXNrlCT6roXKpCgIb21zhRKcqR1ht49dQDtvEzM8/HziVVAp8Zw8pda9A+F0nBzu7 uc48+cJ/+7ui/qGx+jllbGX0qFalpa4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: David Hildenbrand Cc: Joanne Koong , miklos@szeredi.hu, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, jefflexu@linux.alibaba.com, bernd.schubert@fastmail.fm, ziy@nvidia.com, jlayton@kernel.org, kernel-team@meta.com, Miklos Szeredi Subject: Re: [PATCH v7 1/3] mm: add AS_WRITEBACK_INDETERMINATE mapping flag Message-ID: References: <20250404181443.1363005-1-joannelkoong@gmail.com> <20250404181443.1363005-2-joannelkoong@gmail.com> <0462bb5b-c728-4aef-baaf-a9da7398479f@redhat.com> <221860f0-092c-47f1-a6f8-ebbe96429b1a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <221860f0-092c-47f1-a6f8-ebbe96429b1a@redhat.com> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3AC9DA001A X-Stat-Signature: 93gizofmmxz6bnc6zmmkqyjq5y7twycn X-HE-Tag: 1744236325-529945 X-HE-Meta: U2FsdGVkX1/wjxLbyoE7XET3+bz31d8seEjzdMjVBQFQ/+IPjep7yCQkYvM5bLlIRWQcOv/AtYcIvYfg0AiIre7/xbH+FOiIqxJVoBb2mF2qs7sD8vA6ydYMTj7QuszDuXWdvXXbBnctXZRnesBXkw1BxS2CAiliVOrWlzWEqJeEFY9DXHtMNZqHQthqWuO+aeCiMg7VdyIE6zarlr0M2vUOUuBZ4DZdjZ2VlRRWiUPPZNOZEAeogASxW2GJ/7xHokiUjdA2xT0HhruTc8PriGWBy0VSg/GhzSxCFpznyCHirI7gYWbqqGv7efE8stg41BsH0/8ERn0d0R4daAXr8u2CxSLaocezXfM1H0KfYsz6nciw1JzzQ2vlS+58donl7159AZKPNRZy96WeUQlDe6RVTaWLQkyh/VvfpHTE6Letuk1mAHXdLoRTb9MM9DSlxwQUPxpOHoy1zLYufmRMKuweu7jUA9OE09ayK2ZmXznFfnCezZleMcAcwwt0AiOBf8PSam//UIV82yQ8C6sLhP+zmpm8DoUjrwuih+cmXIdyAI1vifV0kYuL6SkJHYMbSvmDudXofNNLWR/IYTC8zQ6Z7HczIXQMZrS9yJwmyAmGTy9sacC3P3AGgO8N1fpbKqWd4WJgppcAEBnFBxyT+VSsz60Xq4rykxlAgAzQewFDlMnFtT5upTYOTSazgWrtFIum3ZZrsOOkqjb2aeB0QGtQS+LQreIfu4Ca76zD7vWLNzt8ohO3uFoXe5VZOtrNJh6j0eX4M90Q39huqxR/4bRWnis2PcKbJhi2+9GLOcPFNVVOfAaWxdyxySwRfurEHuGG9T6qxMOj5qZd7z05ywkgVGn2Dr6biT2nFdngFhjmRLg2zBNgc63FPgkgyno3L9XTGg+t6rUA8n8ERKLjQBWyI0YkkLxh 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 Fri, Apr 04, 2025 at 10:13:55PM +0200, David Hildenbrand wrote: > On 04.04.25 22:09, Joanne Koong wrote: > > On Fri, Apr 4, 2025 at 12:13 PM David Hildenbrand wrote: > > > > > > On 04.04.25 20:14, Joanne Koong wrote: > > > > Add a new mapping flag AS_WRITEBACK_INDETERMINATE which filesystems may > > > > set to indicate that writing back to disk may take an indeterminate > > > > amount of time to complete. Extra caution should be taken when waiting > > > > on writeback for folios belonging to mappings where this flag is set. > > > > > > > > Signed-off-by: Joanne Koong > > > > Reviewed-by: Shakeel Butt > > > > Acked-by: Miklos Szeredi > > > > --- > > > > include/linux/pagemap.h | 11 +++++++++++ > > > > 1 file changed, 11 insertions(+) > > > > > > > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > > > > index 26baa78f1ca7..762575f1d195 100644 > > > > --- a/include/linux/pagemap.h > > > > +++ b/include/linux/pagemap.h > > > > @@ -210,6 +210,7 @@ enum mapping_flags { > > > > AS_STABLE_WRITES = 7, /* must wait for writeback before modifying > > > > folio contents */ > > > > AS_INACCESSIBLE = 8, /* Do not attempt direct R/W access to the mapping */ > > > > + AS_WRITEBACK_INDETERMINATE = 9, /* Use caution when waiting on writeback */ > > > > /* Bits 16-25 are used for FOLIO_ORDER */ > > > > AS_FOLIO_ORDER_BITS = 5, > > > > AS_FOLIO_ORDER_MIN = 16, > > > > @@ -335,6 +336,16 @@ static inline bool mapping_inaccessible(struct address_space *mapping) > > > > return test_bit(AS_INACCESSIBLE, &mapping->flags); > > > > } > > > > > > > > +static inline void mapping_set_writeback_indeterminate(struct address_space *mapping) > > > > +{ > > > > + set_bit(AS_WRITEBACK_INDETERMINATE, &mapping->flags); > > > > +} > > > > + > > > > +static inline bool mapping_writeback_indeterminate(struct address_space *mapping) > > > > +{ > > > > + return test_bit(AS_WRITEBACK_INDETERMINATE, &mapping->flags); > > > > +} > > > > + > > > > static inline gfp_t mapping_gfp_mask(struct address_space * mapping) > > > > { > > > > return mapping->gfp_mask; > > > > > > Staring at this again reminds me of my comment in [1] > > > > > > " > > > b) Call it sth. like AS_WRITEBACK_MIGHT_DEADLOCK_ON_RECLAIM to express > > > that very deadlock problem. > > > " > > > > > > In the context here now, where we really only focus on the reclaim > > > deadlock that can happen for trusted FUSE servers during reclaim, would > > > it make sense to call it now something like that? > > > > Happy to make this change. My thinking was that > > 'AS_WRITEBACK_INDETERMINATE' could be reused in the future for stuff > > besides reclaim, but we can cross that bridge if that ends up being > > the case. > > Yes, but I'm afraid one we start using it in other context we're reaching > the point where we are trying to deal with untrusted user space and the page > lock would already be a similar problem. > > Happy to be wrong on this one. > > Wait for other opinions first. Apart from that, no objection from my side. I am on-board with keeping it specific to reclaim deadlock avoidance and naming it such.