From: Dave Chinner <dgc@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Morduan Zang <zhangdandan@uniontech.com>,
cem@kernel.org, zhanjun@uniontech.com, hch@lst.de,
dchinner@redhat.com, stable@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+d78ace33ad4ee69329d5@syzkaller.appspotmail.com
Subject: Re: [PATCH] xfs: use GFP_NOFS in __xfs_trans_alloc
Date: Fri, 13 Mar 2026 07:28:11 +1100 [thread overview]
Message-ID: <abMh2395Dkbrdgy0@dread> (raw)
In-Reply-To: <20260312142601.GI1770774@frogsfrogsfrogs>
On Thu, Mar 12, 2026 at 07:26:01AM -0700, Darrick J. Wong wrote:
> On Thu, Mar 12, 2026 at 03:22:14PM +0800, Morduan Zang wrote:
> > __xfs_trans_alloc() allocates the transaction structure before
> > xfs_trans_set_context() establishes the nofs context. If memory reclaim
> > enters XFS through xfs_vn_sync_lazytime(), this GFP_KERNEL allocation can
> > trigger a warning from the reclaim path.
> >
> > Use GFP_NOFS for the transaction allocation to avoid filesystem reclaim
> > recursion before the nofs context is set.
>
> Why doesn't filesystem reclaim itself set PF_MEMALLOC_NOFS for us?
Because kswapd based memory reclaim runs in GFP_KERNEL
memory allocation context. i.e. we're not in a recursion path here
potentially holding other filesystem resources that we could
deadlock on.
i.e. GFP_NOFS allocations are used to stop -direct reclaim- from
recursing back into filesystem reclaim - it does not (and should
not) stop kswapd from being able to reclaim filesystem objects.
-Dave.
--
Dave Chinner
dgc@kernel.org
next prev parent reply other threads:[~2026-03-12 20:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 7:22 [PATCH] xfs: use GFP_NOFS in __xfs_trans_alloc Morduan Zang
2026-03-12 14:26 ` Darrick J. Wong
2026-03-12 20:28 ` Dave Chinner [this message]
2026-03-12 20:25 ` Dave Chinner
2026-03-16 9:18 ` Christoph Hellwig
2026-03-18 21:01 ` Dave Chinner
2026-03-20 10:03 ` [PATCH] xfs: defer lazytime timestamp updates to inodegc during eviction Morduan Zang
2026-03-24 15:14 ` Jan Kara
2026-03-25 6:38 ` Christoph Hellwig
2026-03-25 11:34 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abMh2395Dkbrdgy0@dread \
--to=dgc@kernel.org \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+d78ace33ad4ee69329d5@syzkaller.appspotmail.com \
--cc=zhangdandan@uniontech.com \
--cc=zhanjun@uniontech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.