All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Qiang Ma <maqianga@uniontech.com>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: clear zapped attr fork state when bmap repair finds no attr fork
Date: Wed, 15 Jul 2026 10:32:16 -0700	[thread overview]
Message-ID: <20260715173216.GO7380@frogsfrogsfrogs> (raw)
In-Reply-To: <20260715103026.1701559-1-maqianga@uniontech.com>

On Wed, Jul 15, 2026 at 06:30:26PM +0800, Qiang Ma wrote:
> xfstests xfs/377 can make xfs_scrub repeatedly check and repair the
> attr block map after inode repair zaps an attr fork.
> 
> When inode repair zaps an attr fork, it records
> XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork
> block map.  If the fork has been reset to an empty state and removed,
> BMBTA repair has no attr fork mappings to rebuild and can return success.
> 
> The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means
> xchk_file_looks_zapped() deliberately ignores the stale zapped health bit
> and asks xchk_bmap() to check the current attr fork.  For an absent attr
> fork, xchk_bmap() returns -ENOENT.  Returning that error prevents
> xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving
> the zapped health state behind even though there are no attr fork mappings
> left to check.
> 
> Treat -ENOENT during post-repair BMBTA revalidation as a clean result for
> the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success.
> Keep the existing -ENOENT behavior for ordinary scrubs of absent attr
> forks.
> 
> Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork")
> Signed-off-by: Qiang Ma <maqianga@uniontech.com>
> ---
>  fs/xfs/scrub/bmap.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/xfs/scrub/bmap.c b/fs/xfs/scrub/bmap.c
> index 70028da1aacc7..0cee51d4338e4 100644
> --- a/fs/xfs/scrub/bmap.c
> +++ b/fs/xfs/scrub/bmap.c
> @@ -1170,6 +1170,11 @@ xchk_bmap_attr(
>  	}
>  
>  	error = xchk_bmap(sc, XFS_ATTR_FORK);
> +	if (error == -ENOENT && (sc->flags & XREP_ALREADY_FIXED)) {
> +		/* A repaired, empty attr fork no longer has mappings to check. */
> +		xchk_mark_healthy_if_clean(sc, XFS_SICK_INO_BMBTA_ZAPPED);
> +		return 0;
> +	}

That makes sense.

Cc: <stable@vger.kernel.org> # v6.8
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

>  	if (error)
>  		return error;
>  
> -- 
> 2.20.1
> 
> 
> 

  reply	other threads:[~2026-07-15 17:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 10:30 [PATCH] xfs: clear zapped attr fork state when bmap repair finds no attr fork Qiang Ma
2026-07-15 17:32 ` Darrick J. Wong [this message]
2026-07-16  8:26 ` Christoph Hellwig

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=20260715173216.GO7380@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=maqianga@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.