From: Dave Chinner <dgc@kernel.org>
To: Ravi Singh <ravising@redhat.com>
Cc: linux-xfs@vger.kernel.org, dchinner@redhat.com,
bfoster@redhat.com, hch@lst.de, djwong@kernel.org,
cem@kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] xfs: punch COW fork delalloc on COW writeback failure
Date: Thu, 9 Jul 2026 17:58:33 +1000 [thread overview]
Message-ID: <ak9UqRfSB_O7vDVM@dread> (raw)
In-Reply-To: <20260709062622.2939412-1-ravising@redhat.com>
On Thu, Jul 09, 2026 at 06:26:22AM +0000, Ravi Singh wrote:
> When a COW writeback I/O fails, xfs_end_ioend_write() cancels the COW
> fork extents and punches out any overlapping delalloc blocks. Currently
> the delalloc punch targets XFS_DATA_FORK, but on the error path
> xfs_reflink_end_cow() is never called, so the COW fork extents have not
> been moved to the data fork yet. Any overlapping delalloc that needs to
> be cleaned up is therefore still in the COW fork.
>
> Punching the data fork is incorrect because it can remove delalloc
> reservations that belong to a concurrent buffered write. In particular,
> the convert_delay path in xfs_buffered_write_iomap_begin() drops the
> ILOCK before calling xfs_bmapi_convert_delalloc(), and a concurrent COW
> writeback failure punching data fork delalloc during this window causes
> xfs_bmapi_convert_one_delalloc() to find the extent missing and trigger
> a WARN_ON_ONCE(whichfork != XFS_COW_FORK).
>
> This is the same class of wrong-fork issue fixed by commit f6f91d290c8b
> ("xfs: punch delalloc extents from the COW fork for COW writes") for the
> xfs_buffered_write_iomap_end() path.
I know I suggested that punching the wrong fork -might- be the cause
of the bug you were trying to reproduce after noticing that commit
reference in your analysis, but I don't think my hypothesis was
correct.
I've had reason to look at xfs_reflink_cancel_cow_range() very
closely today, and I think you should, too. i.e. work out what the
COW fork should contain after it finishes running on the range the
IO spanned.
Then....
> Fix xfs_end_ioend_write() to punch delalloc from XFS_COW_FORK instead
> of XFS_DATA_FORK for IOMAP_IOEND_SHARED ioends.
... it should become clear that COW fork doesn't actually contain
any delalloc extents over the given range after the cancel operation
returns.
So even if punching the data fork is wrong or triggering some other
data fork extent manipulation race, replacing it with a cow fork
punch is not a fix for whatever the underlying issue might be.
Cheers,
Dave.
--
Dave Chinner
dgc@kernel.org
next prev parent reply other threads:[~2026-07-09 7:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 6:26 [PATCH] xfs: punch COW fork delalloc on COW writeback failure Ravi Singh
2026-07-09 7:58 ` Dave Chinner [this message]
2026-07-09 12:02 ` Ravi Singh
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=ak9UqRfSB_O7vDVM@dread \
--to=dgc@kernel.org \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ravising@redhat.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