public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Zorro Lang <zlang@kernel.org>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] xfs: flush inodegc before swapon
Date: Thu, 6 Feb 2025 08:08:14 +1100	[thread overview]
Message-ID: <Z6PTPoYfyn-1-hHr@dread.disaster.area> (raw)
In-Reply-To: <20250205162813.2249154-2-hch@lst.de>

On Wed, Feb 05, 2025 at 05:28:00PM +0100, Christoph Hellwig wrote:
> Fix the brand new xfstest that tries to swapon on a recently unshared
> file and use the chance to document the other bit of magic in this
> function.

You haven't documented the magic at all - I have no clue what the
bug being fixed is nor how adding an inodegc flush fixes anything
to do with swap file activation....

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_aops.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 69b8c2d1937d..c792297aa0a3 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -21,6 +21,7 @@
>  #include "xfs_error.h"
>  #include "xfs_zone_alloc.h"
>  #include "xfs_rtgroup.h"
> +#include "xfs_icache.h"
>  
>  struct xfs_writepage_ctx {
>  	struct iomap_writepage_ctx ctx;
> @@ -685,7 +686,22 @@ xfs_iomap_swapfile_activate(
>  	struct file			*swap_file,
>  	sector_t			*span)
>  {
> -	sis->bdev = xfs_inode_buftarg(XFS_I(file_inode(swap_file)))->bt_bdev;
> +	struct xfs_inode		*ip = XFS_I(file_inode(swap_file));
> +
> +	/*
> +	 * Ensure inode GC has finished to remove unmapped extents, as the
> +	 * reflink bit is only cleared once all previously shared extents
> +	 * are unmapped.  Otherwise swapon could incorrectly fail on a
> +	 * very recently unshare file.
> +	 */
> +	xfs_inodegc_flush(ip->i_mount);

The comment doesn't explains what this actually fixes. Inodes that
are processed by inodegc *must* be unreferenced by the VFS, so it
is not clear exactly what this is actually doing.

I'm guessing that the test in question is doing something like this:

	file2 = clone(file1)
	unlink(file1)
	swapon(file2)

and so the swap file activation is racing with the background
inactivation and extent removal of file1?

But in that case, the extents are being removed from file1, and at
no time does that remove the reflink bit on file2. i.e. even if the
inactivation of file1 results in all the extents in file2 no longer
being shared, that only results in refcountbt updates and it does
not get propagated back to file2's inode. i.e. file2 will still be
marked as a reflink file containing shared extents.

So I'm kinda clueless as to what this change is actually
doing/fixing because the comments and commit message do not describe
the bug that is being fixed, nor how the change fixes that bug.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2025-02-05 21:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 16:27 fix swapon for recently unshared blocks Christoph Hellwig
2025-02-05 16:28 ` [PATCH 1/2] xfs: flush inodegc before swapon Christoph Hellwig
2025-02-05 18:23   ` Darrick J. Wong
2025-02-05 21:08   ` Dave Chinner [this message]
2025-02-05 21:16     ` Darrick J. Wong
2025-02-05 21:53       ` Dave Chinner
2025-02-05 22:05         ` Darrick J. Wong
2025-02-05 16:28 ` [PATCH 2/2] xfs: rename xfs_iomap_swapfile_activate to xfs_vm_swap_activate Christoph Hellwig
2025-02-05 18:24   ` Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2025-02-06  6:14 fix swapon for recently unshared blocks v2 Christoph Hellwig
2025-02-06  6:15 ` [PATCH 1/2] xfs: flush inodegc before swapon Christoph Hellwig
2025-02-11  8:44   ` Carlos Maiolino

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=Z6PTPoYfyn-1-hHr@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@kernel.org \
    /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