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 EC455C47422 for ; Thu, 18 Jan 2024 23:39:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83F666B0075; Thu, 18 Jan 2024 18:39:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EF876B00A4; Thu, 18 Jan 2024 18:39:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DE326B00A5; Thu, 18 Jan 2024 18:39:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5E6B26B0075 for ; Thu, 18 Jan 2024 18:39:20 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3218F120BDC for ; Thu, 18 Jan 2024 23:39:20 +0000 (UTC) X-FDA: 81694050480.08.9A19674 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf09.hostedemail.com (Postfix) with ESMTP id DE82614000F for ; Thu, 18 Jan 2024 23:39:17 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Qa/pYQZK"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705621158; 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=u/3nqzCR55z2i/KDNzm/TR5aI70UxZoSxH/yftPyHzo=; b=EeXBOlbCwYAYpKu4r90f7lQ2h+Stq3eS3n/174fU1P/7D1qFxvDyJgTEVffopgaPqPnnzc nvO1feaKi4lpQhRFMxl5zPyh9TAvqqc3xjYMWNVpaDnA0bbE6srz2rSqQPX0FAZVDIMYaw QD/EopVWwF76joAXt4LbvbkEqGbLIPU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Qa/pYQZK"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705621158; a=rsa-sha256; cv=none; b=O5PcXB1dpgeRVuuwQh+CYQ5pIo2uryzC6pOx5YKoXluD2BV8sddPRV3Es3xrBIh6Ie9l4w AVxqNllen+TXJAbAYaAjQ+lmaphksVOvdRoTsJj0chog4+NEVzSrAVyHr6ZITIHkiZh622 M62KFo6sRxFXXfPTrOI+I9AVChMSANc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 00881CE20C9; Thu, 18 Jan 2024 23:39:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32A0EC433C7; Thu, 18 Jan 2024 23:39:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705621153; bh=kBi8sr7d6KMQKJ8NlGPfcvv71UswaZSW8Fst7sMA0XY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Qa/pYQZKCap9UNr96UVdEaAmO8UW/fk4HZ/ZHED47IJBRPO2EzC44+HuJz8G56uKU kTmkwY1Y6s0fkNJ6r3i2OyJS/OzYoA8AyL65EdHRdWCrsgiWDPx4ML4kcL1wMT8ny7 AYyIDi1krn808alqxYfqAhcer2cJ425f60qrfi0xYJj63H9Xag+JEOhMoBBOnjKS/q hafbfhlvBIixrmIVhGbYvgCCi5zKDEdaKC9Uas7i7+6+KC8rRt6WaoCCuDaotSe2Yh tL7Kk4mjeUiMppHHTogqWam6HAm8KJjuypjGUcQZTVi5xN32KuwAK5TJTjRqEY0JpM P5ATEoTEDfRHQ== Date: Thu, 18 Jan 2024 15:39:12 -0800 From: "Darrick J. Wong" To: Dave Chinner Cc: linux-xfs@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 09/12] xfs: place intent recovery under NOFS allocation context Message-ID: <20240118233912.GL674499@frogsfrogsfrogs> References: <20240115230113.4080105-1-david@fromorbit.com> <20240115230113.4080105-10-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240115230113.4080105-10-david@fromorbit.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DE82614000F X-Stat-Signature: 9dciot95d3147xr95pjs4fopgpmpok5c X-HE-Tag: 1705621157-426370 X-HE-Meta: U2FsdGVkX18jEWb8gVgjSq5rQAPcUxjtYOort5xXLiqKDBdFNUHtJybwyQRt/RllLFHYWcxWnC0quM8VedF2wabNIwl5pK47X2jmn7BhoY6QNVSFUj+9GjubM/zDb5rNBaRNjeZ66Kejh4a5YOcdHjSa5WG0qHewLdbOis4rs9g/tj+5fNGgyR6zQglI3BKH67VOMXux5ps6gQnmgS1BPDP3m996E7psJFAF3vRhVwNYDyQni7HPzzN4PeYjDGdCPuGJ5yNaURlmiPL4UuiD7UDS4H1AQhL+onJGL7wUMZOpuup1k9wfwf5XzL52laGJ/3tfyM31uzsx6HRb7nTZh4yL/qNk80vwvzzB/YMlejuuTq3vYMmLk3d7kGwCHSECCAzMnxZYXdeSfcBHgZXsDFZ62APJBKW0zM8Us3pkt6dCcIkuavoTKT1ZTeK8Pwchhz6YA+w79lCU4ZQH5MWjsBlyZC5hmY5gjst10DdRTv1eKl6wRjwjrAD/iqm+YhSZ8AX1M0GpmRovPr1PJ27nHm7wr1PGHWN17skFDy6oUyhik3aQAQKC1vbrk4StK/6lKz/LnrYpFjwMWMjLzQNuYAiPwGqAUpqw4KnzVPPMoN+4O1jxusa2FWLHper71syT961aDNi08G3hIWudO6CAU/xIS1G3+onzYj2s8jCGQXQ+PBAYgyiMcnVWUgf8+ZS/cjmuxNGk3ng4xirz7Qz/yRDdevr23nCiHDTX1fooGmYfa00fokR/yalTyohQ6yUXo/SbG2HsR0i2ou/2RMqjOrI6TXTThVgxET0m0P+M9JtFT+bkUHEjXrff7nhMZyN+ObGqNKnbuAo5W75Hz7YmfDhPdkUGhicZQe94x0SYkmtVP2FzCGDyLDma+hkMYr+BW8hhZRW76R/oFL0d3LaqahS+N0PbSdybS0mON6tXD22RkW5tSAsCHyoeeFMJuTrnDspBixZufhp9HPneCkU GwRXXmLP aMccGO4rP2Nvhd8ian0PSLt3Ux0hfJmUYQSwtlzVDmvDC/Dgny/dpT6ToZ3zLgjCtlR3ZqP0PkTiYH7KOyR9mDLW66sb0ekn/tWF6f1L3eWMU5UmutqcdGlJSFPkOTJGZDkf1J/BIvTfSDi2m/Cc0FZlX08U/VP7hOEMKUFELnksxsBb/m/IQFvQFjx77Fkh5tXooWqS5kOS01ZuYweVcTwbFRpa5ngsxCus8XexCJIXJZcJPzMz1XYTu+veeRSkoo9fc0BsgD9OrTkQ= 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 Tue, Jan 16, 2024 at 09:59:47AM +1100, Dave Chinner wrote: > From: Dave Chinner > > When recovery starts processing intents, all of the initial intent > allocations are done outside of transaction contexts. That means > they need to specifically use GFP_NOFS as we do not want memory > reclaim to attempt to run direct reclaim of filesystem objects while > we have lots of objects added into deferred operations. > > Rather than use GFP_NOFS for these specific allocations, just place > the entire intent recovery process under NOFS context and we can > then just use GFP_KERNEL for these allocations. > > Signed-off-by: Dave Chinner Hooray! This finally goes away... Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/xfs_attr_item.c | 2 +- > fs/xfs/xfs_bmap_item.c | 3 ++- > fs/xfs/xfs_log_recover.c | 18 ++++++++++++++---- > fs/xfs/xfs_refcount_item.c | 2 +- > fs/xfs/xfs_rmap_item.c | 2 +- > 5 files changed, 19 insertions(+), 8 deletions(-) > > diff --git a/fs/xfs/xfs_attr_item.c b/fs/xfs/xfs_attr_item.c > index 0bf25a2ba3b6..e14e229fc712 100644 > --- a/fs/xfs/xfs_attr_item.c > +++ b/fs/xfs/xfs_attr_item.c > @@ -513,7 +513,7 @@ xfs_attri_recover_work( > return ERR_PTR(error); > > attr = kzalloc(sizeof(struct xfs_attr_intent) + > - sizeof(struct xfs_da_args), GFP_NOFS | __GFP_NOFAIL); > + sizeof(struct xfs_da_args), GFP_KERNEL | __GFP_NOFAIL); > args = (struct xfs_da_args *)(attr + 1); > > attr->xattri_da_args = args; > diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c > index 029a6a8d0efd..e3c58090e976 100644 > --- a/fs/xfs/xfs_bmap_item.c > +++ b/fs/xfs/xfs_bmap_item.c > @@ -445,7 +445,8 @@ xfs_bui_recover_work( > if (error) > return ERR_PTR(error); > > - bi = kmem_cache_zalloc(xfs_bmap_intent_cache, GFP_NOFS | __GFP_NOFAIL); > + bi = kmem_cache_zalloc(xfs_bmap_intent_cache, > + GFP_KERNEL | __GFP_NOFAIL); > bi->bi_whichfork = (map->me_flags & XFS_BMAP_EXTENT_ATTR_FORK) ? > XFS_ATTR_FORK : XFS_DATA_FORK; > bi->bi_type = map->me_flags & XFS_BMAP_EXTENT_TYPE_MASK; > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c > index e9ed43a833af..8c1d260bb9e1 100644 > --- a/fs/xfs/xfs_log_recover.c > +++ b/fs/xfs/xfs_log_recover.c > @@ -3443,12 +3443,19 @@ xlog_recover( > * part of recovery so that the root and real-time bitmap inodes can be read in > * from disk in between the two stages. This is necessary so that we can free > * space in the real-time portion of the file system. > + * > + * We run this whole process under GFP_NOFS allocation context. We do a > + * combination of non-transactional and transactional work, yet we really don't > + * want to recurse into the filesystem from direct reclaim during any of this > + * processing. This allows all the recovery code run here not to care about the > + * memory allocation context it is running in. > */ > int > xlog_recover_finish( > struct xlog *log) > { > - int error; > + unsigned int nofs_flags = memalloc_nofs_save(); > + int error; > > error = xlog_recover_process_intents(log); > if (error) { > @@ -3462,7 +3469,7 @@ xlog_recover_finish( > xlog_recover_cancel_intents(log); > xfs_alert(log->l_mp, "Failed to recover intents"); > xlog_force_shutdown(log, SHUTDOWN_LOG_IO_ERROR); > - return error; > + goto out_error; > } > > /* > @@ -3483,7 +3490,7 @@ xlog_recover_finish( > if (error < 0) { > xfs_alert(log->l_mp, > "Failed to clear log incompat features on recovery"); > - return error; > + goto out_error; > } > } > > @@ -3508,9 +3515,12 @@ xlog_recover_finish( > * and AIL. > */ > xlog_force_shutdown(log, SHUTDOWN_LOG_IO_ERROR); > + goto out_error; > } > > - return 0; > +out_error: > + memalloc_nofs_restore(nofs_flags); > + return error; > } > > void > diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c > index d850b9685f7f..14919b33e4fe 100644 > --- a/fs/xfs/xfs_refcount_item.c > +++ b/fs/xfs/xfs_refcount_item.c > @@ -425,7 +425,7 @@ xfs_cui_recover_work( > struct xfs_refcount_intent *ri; > > ri = kmem_cache_alloc(xfs_refcount_intent_cache, > - GFP_NOFS | __GFP_NOFAIL); > + GFP_KERNEL | __GFP_NOFAIL); > ri->ri_type = pmap->pe_flags & XFS_REFCOUNT_EXTENT_TYPE_MASK; > ri->ri_startblock = pmap->pe_startblock; > ri->ri_blockcount = pmap->pe_len; > diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c > index a40b92ac81e8..e473124e29cc 100644 > --- a/fs/xfs/xfs_rmap_item.c > +++ b/fs/xfs/xfs_rmap_item.c > @@ -455,7 +455,7 @@ xfs_rui_recover_work( > { > struct xfs_rmap_intent *ri; > > - ri = kmem_cache_alloc(xfs_rmap_intent_cache, GFP_NOFS | __GFP_NOFAIL); > + ri = kmem_cache_alloc(xfs_rmap_intent_cache, GFP_KERNEL | __GFP_NOFAIL); > > switch (map->me_flags & XFS_RMAP_EXTENT_TYPE_MASK) { > case XFS_RMAP_EXTENT_MAP: > -- > 2.43.0 > >