public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <dgc@kernel.org>
To: Morduan Zang <zhangdandan@uniontech.com>
Cc: 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:25:05 +1100	[thread overview]
Message-ID: <abMhIabvChMOsUrY@dread> (raw)
In-Reply-To: <24B50BB66059E3C8+20260312072214.475115-1-zhangdandan@uniontech.com>

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.

PLease include the warning and stack trace in the commit message.

> Use GFP_NOFS for the transaction allocation to avoid filesystem reclaim
> recursion before the nofs context is set.
> 
> Link: https://syzkaller.appspot.com/bug?extid=d78ace33ad4ee69329d5

That's a PF_MEMALLOC + __GFP_NOFAIL warning. Has nothing to do
with GFP_NOFS.

> Fixes: 83a80e95e797 ("xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc")

Nope. That commit didn't even change the allocation context....

Indeed, the stack trace trivially demonstrates the cause - the
sync_lazytime() changes (in 6.19i, IIRC) have put a new XFS
transaction in the iput() path that memory reclaim runs.

We managed to remove all the xfs transactions in this path with the
introduction of the background inodegc infrastructure because
lockdep, memory allocation and other stuff really don't like us
running "must succeed" transactions in the memory reclaim path.

Hence putting a new transaction directly in that path is a
regression, and so I suspect the sync_lazytime() call directly from
iput() running a transaction needs to be rethought...

-Dave.
-- 
Dave Chinner
dgc@kernel.org

  parent reply	other threads:[~2026-03-12 20:25 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
2026-03-12 20:25 ` Dave Chinner [this message]
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=abMhIabvChMOsUrY@dread \
    --to=dgc@kernel.org \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox