From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs: fix XFS_ERRTAG_FORCE_ZERO_RANGE for zoned file system
Date: Fri, 19 Dec 2025 09:01:38 -0500 [thread overview]
Message-ID: <aUVawo2af1SHS47z@bfoster> (raw)
In-Reply-To: <20251219052803.GA29788@lst.de>
On Fri, Dec 19, 2025 at 06:28:03AM +0100, Christoph Hellwig wrote:
> On Tue, Dec 16, 2025 at 01:57:43PM -0500, Brian Foster wrote:
> > > + if (xfs_is_zoned_inode(ip)) {
> > > + if (ac->reserved_blocks > XFS_ZONED_ZERO_EDGE_SPACE_RES) {
> > > + ASSERT(IS_ENABLED(CONFIG_XFS_DEBUG));
> >
> > JFYI the reason I suggested a config check was as a safeguard against
> > forced zeroing on production kernels. The assert here would compile out
> > in that case, so won't necessarily provide that benefit (unless you
> > wanted to use ASSERT_ALWAYS() or WARN() or something..).
> >
> > A warning on WARN && !DEBUG is still useful so I don't really care if
> > you leave it as is or tweak it. I just wanted to point that out.
>
> I really think that anyone who modidifies this area should run a debug
> kernel to test. And if they the usual automated runs will catch it.
> Having allocation beahvior modified based on CONFIG_XFS_DEBUG, and only
> for a case that isn't supposed to happen seems weird and in would cause
> weird heisenbugs if it ever hit.
>
I agree on testing but XFS_DEBUG has always included some quirks that
alter algorithms and such to improve test coverage in this way. The
subtlety here is that this will only "catch it" on XFS_WARN (i.e.
!XFS_DEBUG). Otherwise this will quietly do forced zeroing. The
userspace tests should ideally pass because iomap zeroing is generally
expected to work, so there's no presumed test failure to rely on to
detect this. The assert won't fire unless XFS_WARN because either
XFS_DEBUG is enabled (so the assert passes) or if on a production
kernel, then the assert is compiled out.
I think if we broke it we'd eventually catch it one way or another, such
as if anybody is testing XFS_WARN regularly(?), but that loose end was
my reasoning for at least enforcing that production kernels run as
expected no matter what. Alternatively if we changed it to WARN_ON_ONCE
then that might provide more of a guarantee. But again just my .02.
Brian
prev parent reply other threads:[~2025-12-19 14:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <P_OCd7pNcLvRe038VeBLKmIi6KSgitIcPVyjn56Ucs9A34-ckTtKbjGP08W5TLKsAjB8PriOequE0_FNUOny-Q==@protonmail.internalid>
2025-12-15 6:05 ` [PATCH v2] xfs: fix XFS_ERRTAG_FORCE_ZERO_RANGE for zoned file system Christoph Hellwig
2025-12-16 8:03 ` Carlos Maiolino
2025-12-16 8:06 ` Christoph Hellwig
2025-12-16 8:11 ` Carlos Maiolino
2025-12-16 15:54 ` Darrick J. Wong
2025-12-16 17:31 ` Christoph Hellwig
2025-12-16 18:57 ` Brian Foster
2025-12-19 5:28 ` Christoph Hellwig
2025-12-19 14:01 ` Brian Foster [this message]
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=aUVawo2af1SHS47z@bfoster \
--to=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.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