All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
	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 06:28:03 +0100	[thread overview]
Message-ID: <20251219052803.GA29788@lst.de> (raw)
In-Reply-To: <aUGrpyS6BG0CD-kn@bfoster>

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.


  reply	other threads:[~2025-12-19  5:28 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 [this message]
2025-12-19 14:01       ` Brian Foster

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=20251219052803.GA29788@lst.de \
    --to=hch@lst.de \
    --cc=bfoster@redhat.com \
    --cc=cem@kernel.org \
    --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 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.