public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Yuto Ohnuki <ytohnuki@amazon.com>
Cc: Carlos Maiolino <cem@kernel.org>,
	Dave Chinner <dchinner@redhat.com>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Brian Foster <bfoster@redhat.com>,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v3 1/4] xfs: stop reclaim before pushing AIL during unmount
Date: Mon, 9 Mar 2026 09:02:35 -0700	[thread overview]
Message-ID: <20260309160235.GA6033@frogsfrogsfrogs> (raw)
In-Reply-To: <20260308182804.33127-7-ytohnuki@amazon.com>

On Sun, Mar 08, 2026 at 06:28:06PM +0000, Yuto Ohnuki wrote:
> The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while
> background reclaim and inodegc are still running. This creates a race
> where reclaim can free inodes and their log items while the AIL push is
> still referencing them.

Is this a general race between background inode reclaim and AIL pushes?
Or is the race between an AIL push and the explicit call to
xfs_reclaim_inodes below?

I ask because there's a call to xfs_ail_push_all_sync from various
places in the codebase:

- Log covering/quiescing activities

- xchk_checkpoint_log in the online fsck code if the inode btree
  scrubber thinks it's racing with inode reclaim.

If inode reclaim happens to be running at the same time as these AIL
pushes, won't the same race condition manifest there?  But maybe you
meant the race is with the explicit xfs_reclaim_inodes below?

> Reorder xfs_unmount_flush_inodes() to cancel background reclaim and stop
> inodegc before pushing the AIL, so that background reclaim and inodegc
> are no longer running while the AIL is pushed.
> 
> Reported-by: syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c
> Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary")
> Cc: <stable@vger.kernel.org> # v5.9
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
> ---
>  fs/xfs/xfs_mount.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 9c295abd0a0a..786e1fc720e5 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -621,9 +621,9 @@ xfs_unmount_flush_inodes(
>  
>  	xfs_set_unmounting(mp);
>  
> -	xfs_ail_push_all_sync(mp->m_ail);
> -	xfs_inodegc_stop(mp);
>  	cancel_delayed_work_sync(&mp->m_reclaim_work);
> +	xfs_inodegc_stop(mp);

xfs_inodegc_inactivate (aka the inodegc worker) can call
xfs_inodegc_set_reclaimable, which in turn calls xfs_reclaim_work_queue.
That will re-queue m_reclaim_work, which we just cancelled.  I think
inodegc_stop has to come before cancelling m_reclaim_work.

--D

> +	xfs_ail_push_all_sync(mp->m_ail);
>  	xfs_reclaim_inodes(mp);
>  	xfs_health_unmount(mp);
>  	xfs_healthmon_unmount(mp);
> -- 
> 2.50.1
> 
> 
> 
> 
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
> 
> Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
> 
> 
> 
> 

  reply	other threads:[~2026-03-09 16:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260308182804.33127-6-ytohnuki@amazon.com>
2026-03-08 18:28 ` [PATCH v3 1/4] xfs: stop reclaim before pushing AIL during unmount Yuto Ohnuki
2026-03-09 16:02   ` Darrick J. Wong [this message]
2026-03-10 17:33     ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 2/4] xfs: refactor xfsaild_push loop into helper Yuto Ohnuki
2026-03-09 16:14   ` Darrick J. Wong
2026-03-10 17:38     ` Yuto Ohnuki
2026-03-10  5:26   ` Dave Chinner
2026-03-10 17:46     ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 3/4] xfs: avoid dereferencing log items after push callbacks Yuto Ohnuki
2026-03-09 16:27   ` Darrick J. Wong
2026-03-10  5:25     ` Dave Chinner
2026-03-10 17:51     ` Yuto Ohnuki
2026-03-10  5:27   ` Dave Chinner
2026-03-10 17:56     ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 4/4] xfs: save ailp before dropping the AIL lock in " Yuto Ohnuki
2026-03-09 16:28   ` Darrick J. Wong
2026-03-10  5:27   ` Dave Chinner

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=20260309160235.GA6033@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=bfoster@redhat.com \
    --cc=cem@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com \
    --cc=ytohnuki@amazon.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