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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFB6DC4361B for ; Tue, 8 Dec 2020 05:02:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AE9E23A5B for ; Tue, 8 Dec 2020 05:02:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AE9E23A5B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A429E8D0002; Tue, 8 Dec 2020 00:02:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A3918D0001; Tue, 8 Dec 2020 00:02:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86B488D0002; Tue, 8 Dec 2020 00:02:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id 67CC68D0001 for ; Tue, 8 Dec 2020 00:02:17 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 235411EE6 for ; Tue, 8 Dec 2020 05:02:17 +0000 (UTC) X-FDA: 77568918714.05.shoe08_31070b2273e4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 03C3B180206D1 for ; Tue, 8 Dec 2020 05:02:17 +0000 (UTC) X-HE-Tag: shoe08_31070b2273e4 X-Filterd-Recvd-Size: 7403 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Dec 2020 05:02:16 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id i18so15752734ioa.1 for ; Mon, 07 Dec 2020 21:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BjOIiNIARLKGbCL4WsNHg/y/9CkG9Qa/Drt1maYW5Iw=; b=NTglJp1LM2oBXvkzbMWPg0jN+h9rypyRkm22H+yok0+uzCEmlGhclVVu8tEJFgv88a VKrFaFyfuYe5l2pcMQwwhGXJ/01B+V1hkOKvpzkGFr3hRv1O0i7s7tlZMKOmZRjJj9Oo 4kpSItYK0bJjjbtPW7mYiPGq2DIKz+wFTo+Q0iCTzBRzDhScgEJMvJesfmk+ZDiGnKNl BYsxrWg2hkwx6KQd+YnCrO9C4Nzn2UgtPy6GOzZU8riMnsDOoORkibPOVm1vOglUsRYm N3qBBlA8x5RxSrvEiwO6gwD6LI2iWc13K5QOA1o1hjPZ2xrPgRe5AQ/X5FjW4oIamWuV yKCw== 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=BjOIiNIARLKGbCL4WsNHg/y/9CkG9Qa/Drt1maYW5Iw=; b=cBplpCtQoHqR4AJ4zX5ZfSsR0q4hJhNYYxt+gkYwGrLx3lavK5MAlCoUJX9IGVdiYV WBoSCp6e4rCvGBkeHZb9SeeMnDxfQ6fxijGEa6rQllyQw7qOQ5bRac/wsAamn4/uWzJV 2XaJYaX/AErKSACoAHiNN/BYfgT/GAn7yTJEmMB/EVAWpqq72InM28Nywqh3ZiHS8kah CKTcj7ktPcPZsTUUvnWDuB5abFbwgAZasTxhRiCGur5jWFYTrah/ufLsKGTM5xMpV26f QxmaR9IZXOPzFzTwPUR0nr4cabj6i6TzReLkI+FEi0Wv8ldgxC7KrG0aif4vO9VV6rwJ +q0g== X-Gm-Message-State: AOAM532pvtT5JGvaqyBnZc1hdSSpo0Ekmxd14yktoCdY3PalYpncwoXe yfsM/HEC67YZe9Qq2hVf5ql/dz9Bp3iPQZz/ufs= X-Google-Smtp-Source: ABdhPJwPNOB4pambcCqF8NeCShr9QVSscoPYVupfFDxLMbWV7TrxXDU8JlSbny5pUwIt8GLXX7rbcfbn+tbfJaRJcCM= X-Received: by 2002:a02:a152:: with SMTP id m18mr24542685jah.64.1607403736011; Mon, 07 Dec 2020 21:02:16 -0800 (PST) MIME-Version: 1.0 References: <20201208021543.76501-1-laoar.shao@gmail.com> <20201208021543.76501-5-laoar.shao@gmail.com> <20201208042026.GW3913616@dread.disaster.area> In-Reply-To: <20201208042026.GW3913616@dread.disaster.area> From: Yafang Shao Date: Tue, 8 Dec 2020 13:01:40 +0800 Message-ID: Subject: Re: [PATCH v10 4/4] xfs: use current->journal_info to avoid transaction reservation recursion To: Dave Chinner Cc: "Darrick J. Wong" , Matthew Wilcox , Christoph Hellwig , Michal Hocko , Andrew Morton , David Howells , jlayton@redhat.com, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-xfs@vger.kernel.org, Linux MM , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" 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: On Tue, Dec 8, 2020 at 12:20 PM Dave Chinner wrote: > > On Tue, Dec 08, 2020 at 10:15:43AM +0800, Yafang Shao wrote: > > PF_FSTRANS which is used to avoid transaction reservation recursion, is > > dropped since commit 9070733b4efa ("xfs: abstract PF_FSTRANS to > > PF_MEMALLOC_NOFS") and commit 7dea19f9ee63 ("mm: introduce > > memalloc_nofs_{save,restore} API") and replaced by PF_MEMALLOC_NOFS which > > means to avoid filesystem reclaim recursion. > > > > As these two flags have different meanings, we'd better reintroduce > > PF_FSTRANS back. To avoid wasting the space of PF_* flags in task_struct, > > we can reuse the current->journal_info to do that, per Willy. As the > > check of transaction reservation recursion is used by XFS only, we can > > move the check into xfs_vm_writepage(s), per Dave. > > > > To better abstract that behavoir, two new helpers are introduced, as > > follows, > > - xfs_trans_context_active > > To check whehter current is in fs transcation or not > > - xfs_trans_context_swap > > Transfer the transaction context when rolling a permanent transaction > > > > These two new helpers are instroduced in xfs_trans.h. > > > > Cc: Darrick J. Wong > > Cc: Matthew Wilcox (Oracle) > > Cc: Christoph Hellwig > > Cc: Dave Chinner > > Cc: Michal Hocko > > Cc: David Howells > > Cc: Jeff Layton > > Signed-off-by: Yafang Shao > > --- > > fs/iomap/buffered-io.c | 7 ------- > > fs/xfs/xfs_aops.c | 17 +++++++++++++++++ > > fs/xfs/xfs_trans.c | 3 +++ > > fs/xfs/xfs_trans.h | 25 +++++++++++++++++++++++++ > > 4 files changed, 45 insertions(+), 7 deletions(-) > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > index 10cc7979ce38..3c53fa6ce64d 100644 > > --- a/fs/iomap/buffered-io.c > > +++ b/fs/iomap/buffered-io.c > > @@ -1458,13 +1458,6 @@ iomap_do_writepage(struct page *page, struct writeback_control *wbc, void *data) > > PF_MEMALLOC)) > > goto redirty; > > > > - /* > > - * Given that we do not allow direct reclaim to call us, we should > > - * never be called in a recursive filesystem reclaim context. > > - */ > > - if (WARN_ON_ONCE(current->flags & PF_MEMALLOC_NOFS)) > > - goto redirty; > > - > > /* > > * Is this page beyond the end of the file? > > * > > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > > index 2371187b7615..28db93d0da97 100644 > > --- a/fs/xfs/xfs_aops.c > > +++ b/fs/xfs/xfs_aops.c > > @@ -568,6 +568,16 @@ xfs_vm_writepage( > > { > > struct xfs_writepage_ctx wpc = { }; > > > > + /* > > + * Given that we do not allow direct reclaim to call us, we should > > + * never be called while in a filesystem transaction. > > + */ > > + if (xfs_trans_context_active()) { > > + redirty_page_for_writepage(wbc, page); > > + unlock_page(page); > > + return 0; > > + } > > hmmm. Missing warning.... > > > diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h > > index 44b11c64a15e..82c6735e40fc 100644 > > --- a/fs/xfs/xfs_trans.h > > +++ b/fs/xfs/xfs_trans.h > > @@ -268,16 +268,41 @@ xfs_trans_item_relog( > > return lip->li_ops->iop_relog(lip, tp); > > } > > > > +static inline bool > > +xfs_trans_context_active(void) > > +{ > > + /* Use journal_info to indicate current is in a transaction */ > > + if (WARN_ON_ONCE(current->journal_info != NULL)) > > + return true; > > + > > + return false; > > +} > > Ah, this is wrong. The call sites should be: > > if (WARN_ON_ONCE(xfs_trans_context_active())) { > /* do error handling */ > return error_value; > } > > because we might want to use xfs_trans_context_active() to check if > we are in a transaction context or not and that should not generate > a warning. Also, placing the warning at the call site gives a more > accurate indication of which IO path generated the warning.... > Thanks for the explanation. I will update it in the next version. -- Thanks Yafang