[PATCH v6 00/10] reflink and atomic write bugs

[PATCH v6 00/10] reflink and atomic write bugs

[Chris Mason]

Hi everyone,

This series did a few rounds privately, but looks ready for the list
now.  Except for Christoph's patch, these were all found and fixed
by an LLM.

The meat of the series is fixing reflink corner cases that incorrectly
let you write into the source of a reflink.  LLMs also tripped over a
few ways to use atomic writes to expose stale blocks on the drive, and a
few races with realtime flag manipulations.

Carlos and Christoph ran these through fstests (thanks guys).

Chris Mason (9):
  xfs: don't skip the flush before shifting extents
  xfs: flush the shifted range before changing the file
  xfs: don't change the block map under a dirty folio
  iomap: don't punch delalloc under a dirty EOF block
  fs: validate atomic writes after O_APPEND and limits
  xfs: recheck direct write alignment after write checks
  xfs: test for reflink after the dio write checks
  xfs: refuse fallocate racing with realtime flag changes
  xfs: restart faults racing with realtime flag changes

Christoph Hellwig (1):
  xfs: refuse writes to files racing with realtime inode flag changes

 fs/ext4/file.c         |   4 --
 fs/iomap/buffered-io.c |  34 ++++++++--
 fs/read_write.c        |  13 ++++
 fs/xfs/xfs_bmap_util.c |  19 +++++-
 fs/xfs/xfs_file.c      | 150 +++++++++++++++++++++++++++++++++--------
 fs/xfs/xfs_iomap.c     |  33 ++++++++-
 fs/xfs/xfs_reflink.c   |   2 +-
 7 files changed, 215 insertions(+), 40 deletions(-)


base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
--
2.55.0

[PATCH v6 01/10] xfs: don't skip the flush before shifting extents

[Chris Mason]

On an XFS file larger than 4 EiB, collapse range and insert range can
drop dirty data without writing it back, and then fail with
EFSCORRUPTED.

xfs_prepare_shift() flushes the page cache from its offset to EOF, but
passes i_size as the length. Above 4 EiB the end of that range can
overflow and turn negative. filemap_write_and_wait_range() then writes
nothing, but truncate_pagecache_range() takes the end as unsigned and
drops every folio from the start of the range onward.

A delalloc extent under a dropped folio stays in the data fork, and the
shift returns -EFSCORRUPTED for it.

The fix used here is to pass i_size - offset as the length.

Fixes: 7f9f71be84bc ("xfs: extent shifting doesn't fully invalidate page cache")
Fixes: feeb9b269523 ("filemap: skip write and wait if end offset precedes start")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_bmap_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 865aec3ae5ab..537c6b29417c 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -980,7 +980,7 @@ xfs_prepare_shift(
 	 * Writeback and invalidate cache for the remainder of the file as we're
 	 * about to shift down every extent from offset to EOF.
 	 */
-	error = xfs_flush_unmap_range(ip, offset, XFS_ISIZE(ip));
+	error = xfs_flush_unmap_range(ip, offset, XFS_ISIZE(ip) - offset);
 	if (error)
 		return error;
 
-- 
2.55.0

[PATCH v6 02/10] xfs: flush the shifted range before changing the file

[Chris Mason]

If writeback of the range to be shifted fails, collapse range on XFS can
fail with its hole already punched, and insert range with the file
already grown.

Both calls change the file first: collapse range punches its hole, and
insert range grows i_size. Only then does xfs_prepare_shift() flush the
range from the offset to EOF, and that flush fails if the writeback
fails.

The fix used here is to flush and invalidate that range before the file
is changed.

Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_file.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 396aca8c66a9..be1f775128d1 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1201,6 +1201,22 @@ xfs_falloc_setsize(
 			&iattr);
 }

+/*
+ * Collapse and insert range change the file in several steps, and each step
+ * writes back and empties the part of the page cache that it needs.  That can
+ * fail.  Do it here for everything that is going to move, before the first
+ * step, so that a failure leaves the file as it was.  xfs_prepare_shift()
+ * starts one allocation unit before the offset, so do the same.
+ */
+static int
+xfs_falloc_flush_shift_range(
+	struct xfs_inode	*ip,
+	loff_t			offset)
+{
+	offset -= min_t(loff_t, offset, xfs_inode_alloc_unitsize(ip));
+	return xfs_flush_unmap_range(ip, offset, XFS_ISIZE(ip) - offset);
+}
+
 static int
 xfs_falloc_collapse_range(
 	struct file		*file,
@@ -1222,6 +1238,10 @@ xfs_falloc_collapse_range(
 	if (offset + len >= i_size_read(inode))
 		return -EINVAL;

+	error = xfs_falloc_flush_shift_range(XFS_I(inode), offset);
+	if (error)
+		return error;
+
 	error = xfs_collapse_file_space(XFS_I(inode), offset, len, ac);
 	if (error)
 		return error;
@@ -1263,9 +1283,10 @@ xfs_falloc_insert_range(
 	 * fork. This shifts back out beyond EOF, but creates an expectedly
 	 * written post-eof block. The insert is going to flush, unmap and
 	 * cancel prealloc across this whole range, so flush EOF now before we
-	 * bump i_size to provide consistent behavior.
+	 * bump i_size to provide consistent behavior.  Flush and unmap the rest
+	 * of the range as well, so that a failure to do so leaves i_size alone.
 	 */
-	error = filemap_write_and_wait_range(inode->i_mapping, isize, isize);
+	error = xfs_falloc_flush_shift_range(XFS_I(inode), offset);
 	if (error)
 		return error;

--
2.55.0

[PATCH v6 03/10] xfs: don't change the block map under a dirty folio

[Chris Mason]

With CONFIG_TRANSPARENT_HUGEPAGE=y, writeback on XFS can write in place
to a shared block and corrupt the other file that shares it.

xfs_map_blocks() writes in place unless the COW fork has an extent for
the block. write() and write faults reserve one before they dirty a
folio over a shared block, so xfs_flush_unmap_range() writes back and
truncates the range before a clone changes the block map. But the holder
of a GUP write pin takes no filesystem lock, and the truncate keeps a
large dirty folio that straddles the range:

    clone                         pin holder         writeback
    =====                         ==========         =========
    writes the range back
                                  dirties the folio
    truncate keeps the folio
    maps a shared block under it
                                  dirties it again
                                                     finds no COW extent
                                                     writes in place
                                                     /* shared block */

The fix used here is to invalidate the range instead of truncating it,
and to fail the call with -EINVAL if a dirty folio is left, before the
block map changes.

Fixes: 6795801366da ("xfs: Support large folios")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_bmap_util.c | 17 +++++++++++++++--
 fs/xfs/xfs_reflink.c   |  2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 537c6b29417c..4673d5174645 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -863,8 +863,21 @@ xfs_flush_unmap_range(
 	error = filemap_write_and_wait_range(inode->i_mapping, start, end);
 	if (error)
 		return error;
-	truncate_pagecache_range(inode, start, end);
-	return 0;
+
+	/*
+	 * The callers go on to change the block map, so no folio may stay over
+	 * the range.  The holder of a GUP pin can mark a folio dirty again
+	 * after the flush, with no lock of ours.  A truncate drops such a folio
+	 * if it lies inside the range.  If it is a large folio that straddles
+	 * the range, the truncate cannot split it, so it zeroes a part of the
+	 * folio, keeps it, and reports nothing.  The invalidation removes whole
+	 * folios, changes no data, and fails on a dirty folio.
+	 */
+	error = invalidate_inode_pages2_range(inode->i_mapping,
+			start >> PAGE_SHIFT, end >> PAGE_SHIFT);
+	if (error == -EBUSY)
+		error = -EINVAL;
+	return error;
 }
 
 int
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index 104542b10d9e..ff89516154bd 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -1663,7 +1663,7 @@ xfs_reflink_zero_posteof(
 /*
  * Prepare two files for range cloning.  Upon a successful return both inodes
  * will have the iolock and mmaplock held, the page cache of the out file will
- * be truncated, and any leases on the out file will have been broken.  This
+ * be invalidated, and any leases on the out file will have been broken.  This
  * function borrows heavily from xfs_file_aio_write_checks.
  *
  * The VFS allows partial EOF blocks to "match" for dedupe even though it hasn't
-- 
2.55.0

[PATCH v6 04/10] iomap: don't punch delalloc under a dirty EOF block

[Chris Mason]

After a failed buffered write, writeback on XFS can write in place to
the shared block that contains EOF, and corrupt the other file that
shares it.

After a failed buffered write, iomap_write_delalloc_release() punches
the delalloc reservation of the write, except under dirty folios, which
still need it. It looks for dirty folios only up to i_size, and punches
the rest unconditionally. But XFS rounds that punch down to a block
boundary, so the block that contains EOF loses its COW fork reservation,
and writeback goes to the shared block:

    block size 4096, i_size 5000, reservation 4096 to 8192
    searched for dirty folios:  4096 to 5000
    punched unconditionally:    5000 to 8192
    rounded to blocks by XFS:   4096 to 8192

The fix used here is to look for dirty folios up to the end of the block
that contains EOF.

Fixes: f43dc4dc3eff ("iomap: buffered write failure should not truncate the page cache")
Fixes: f6f91d290c8b ("xfs: punch delalloc extents from the COW fork for COW writes")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/iomap/buffered-io.c | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index d6e2f1ded5ca..d0980a7f27d1 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1495,9 +1495,34 @@ static void iomap_write_delalloc_scan(struct inode *inode,
  * mapping_seek_hole_data() will return it, and we will skip the punch because
  * the folio is dirty. THis is incorrect - we always need to punch out delalloc
  * beyond EOF in this case as writeback will never write back and covert that
- * delalloc block beyond EOF. Hence we limit the cached data scan range to EOF,
- * resulting in always punching out the range from the EOF to the end of the
- * range the iomap spans.
+ * delalloc block beyond EOF. Hence we limit the cached data scan range, and
+ * always punch out the range from the end of the scan to the end of the range
+ * the iomap spans.
+ *
+ * The scan cannot simply end at EOF, because EOF is a byte offset and a
+ * delalloc reservation covers whole blocks. If EOF lies inside a block, it
+ * splits that block in two:
+ *
+ *	[block start, EOF)	File data. If it is dirty it will be written
+ *				back, so the block must keep its delalloc
+ *				backing.
+ *	[EOF, block end)	Beyond EOF. By the rule above, this would always
+ *				be punched out.
+ *
+ * Both parts share one reservation, and it cannot be split: a punch of a part
+ * of a block takes away the reservation for the whole block. If the scan ended
+ * at EOF, we would skip the punch for the first part because it is dirty, and
+ * then punch the second part, which takes the reservation away from under the
+ * dirty data in the first part. On XFS, writeback that has lost a COW fork
+ * reservation like this writes in place, over a block that is shared with
+ * another file.
+ *
+ * Hence we treat the EOF block as a whole, and let the cached data over it
+ * decide: the scan range is rounded up to the end of the block that EOF lies
+ * in. If the data over the EOF block is dirty, the scan moves the punch start
+ * past the block. If it is clean, the block is punched like any other block in
+ * the range. Only blocks that start at or beyond EOF are punched
+ * unconditionally. If EOF is block aligned, the round up changes nothing.
  *
  * Intervals are of the form [start_byte, end_byte) (i.e. open ended) because it
  * matches the intervals returned by mapping_seek_hole_data(). i.e. SEEK_DATA
@@ -1511,7 +1536,8 @@ void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte,
 		iomap_punch_t punch)
 {
 	loff_t punch_start_byte = start_byte;
-	loff_t scan_end_byte = min(i_size_read(inode), end_byte);
+	loff_t scan_end_byte = min_t(u64, end_byte,
+			round_up((u64)i_size_read(inode), i_blocksize(inode)));
 
 	/*
 	 * The caller must hold invalidate_lock to avoid races with page faults
-- 
2.55.0

Re: [PATCH v6 04/10] iomap: don't punch delalloc under a dirty EOF block

[Carlos Maiolino]

Adding Christian directly to the Cc list.

On Mon, Nov 09, 2026 at 06:51:15PM -0500, Chris Mason wrote:
> After a failed buffered write, writeback on XFS can write in place to
> the shared block that contains EOF, and corrupt the other file that
> shares it.
> 
> After a failed buffered write, iomap_write_delalloc_release() punches
> the delalloc reservation of the write, except under dirty folios, which
> still need it. It looks for dirty folios only up to i_size, and punches
> the rest unconditionally. But XFS rounds that punch down to a block
> boundary, so the block that contains EOF loses its COW fork reservation,
> and writeback goes to the shared block:
> 
>     block size 4096, i_size 5000, reservation 4096 to 8192
>     searched for dirty folios:  4096 to 5000
>     punched unconditionally:    5000 to 8192
>     rounded to blocks by XFS:   4096 to 8192
> 
> The fix used here is to look for dirty folios up to the end of the block
> that contains EOF.
> 
> Fixes: f43dc4dc3eff ("iomap: buffered write failure should not truncate the page cache")
> Fixes: f6f91d290c8b ("xfs: punch delalloc extents from the COW fork for COW writes")
> Signed-off-by: Chris Mason <mason@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Christian, is it ok with you if I pull this through xfs tree?

Cheers
> ---
>  fs/iomap/buffered-io.c | 34 ++++++++++++++++++++++++++++++----
>  1 file changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index d6e2f1ded5ca..d0980a7f27d1 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1495,9 +1495,34 @@ static void iomap_write_delalloc_scan(struct inode *inode,
>   * mapping_seek_hole_data() will return it, and we will skip the punch because
>   * the folio is dirty. THis is incorrect - we always need to punch out delalloc
>   * beyond EOF in this case as writeback will never write back and covert that
> - * delalloc block beyond EOF. Hence we limit the cached data scan range to EOF,
> - * resulting in always punching out the range from the EOF to the end of the
> - * range the iomap spans.
> + * delalloc block beyond EOF. Hence we limit the cached data scan range, and
> + * always punch out the range from the end of the scan to the end of the range
> + * the iomap spans.
> + *
> + * The scan cannot simply end at EOF, because EOF is a byte offset and a
> + * delalloc reservation covers whole blocks. If EOF lies inside a block, it
> + * splits that block in two:
> + *
> + *	[block start, EOF)	File data. If it is dirty it will be written
> + *				back, so the block must keep its delalloc
> + *				backing.
> + *	[EOF, block end)	Beyond EOF. By the rule above, this would always
> + *				be punched out.
> + *
> + * Both parts share one reservation, and it cannot be split: a punch of a part
> + * of a block takes away the reservation for the whole block. If the scan ended
> + * at EOF, we would skip the punch for the first part because it is dirty, and
> + * then punch the second part, which takes the reservation away from under the
> + * dirty data in the first part. On XFS, writeback that has lost a COW fork
> + * reservation like this writes in place, over a block that is shared with
> + * another file.
> + *
> + * Hence we treat the EOF block as a whole, and let the cached data over it
> + * decide: the scan range is rounded up to the end of the block that EOF lies
> + * in. If the data over the EOF block is dirty, the scan moves the punch start
> + * past the block. If it is clean, the block is punched like any other block in
> + * the range. Only blocks that start at or beyond EOF are punched
> + * unconditionally. If EOF is block aligned, the round up changes nothing.
>   *
>   * Intervals are of the form [start_byte, end_byte) (i.e. open ended) because it
>   * matches the intervals returned by mapping_seek_hole_data(). i.e. SEEK_DATA
> @@ -1511,7 +1536,8 @@ void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte,
>  		iomap_punch_t punch)
>  {
>  	loff_t punch_start_byte = start_byte;
> -	loff_t scan_end_byte = min(i_size_read(inode), end_byte);
> +	loff_t scan_end_byte = min_t(u64, end_byte,
> +			round_up((u64)i_size_read(inode), i_blocksize(inode)));
>  
>  	/*
>  	 * The caller must hold invalidate_lock to avoid races with page faults
> -- 
> 2.55.0
> 
> 

Re: [PATCH v6 04/10] iomap: don't punch delalloc under a dirty EOF block

[Christian Brauner]

On Tue, Nov 10, 2026 at 10:43:37AM +0100, Carlos Maiolino wrote:
> Christian, is it ok with you if I pull this through xfs tree?

Sure,
Acked-by: Christian Brauner <brauner@kernel.org>

-- 

Re: [PATCH v6 04/10] iomap: don't punch delalloc under a dirty EOF block

[Carlos Maiolino]

On Wed, Nov 11, 2026 at 12:21:35PM +0100, Christian Brauner wrote:
> On Tue, Nov 10, 2026 at 10:43:37AM +0100, Carlos Maiolino wrote:
> > Christian, is it ok with you if I pull this through xfs tree?
> 
> Sure,
> Acked-by: Christian Brauner <brauner@kernel.org>

Thanks!

> 
> -- 
> 

[PATCH v6 05/10] fs: validate atomic writes after O_APPEND and limits

[Chris Mason]

An RWF_ATOMIC write on XFS with reflink can expose stale disk contents
if O_APPEND or RLIMIT_FSIZE leaves it sector aligned but not block
aligned.

XFS and ext4 call generic_atomic_write_valid() on the range that the
caller passed. But generic_write_checks() changes the range later:
O_APPEND moves the position, and RLIMIT_FSIZE cuts the length. XFS can
then fill only a part of a new block, and still map the whole block into
the file:

    block size 4096, i_size 512, O_APPEND
    validated:        0 to 4095
    written:          512 to 4607
    new blocks:       0 to 8191
    stale below EOF:  0 to 511

The fix used here is to validate an atomic write in
generic_write_checks(), after its range is final, and to refuse one that
was cut. XFS no longer picks the path of an atomic write by the
alignment of the range that the caller passed.

Fixes: f096207d3276 ("xfs: Validate atomic writes")
Fixes: 43c696f9d094 ("ext4: Check for atomic writes support in write iter")
Signed-off-by: Chris Mason <mason@kernel.org>
---
 fs/ext4/file.c    |  4 ----
 fs/read_write.c   | 13 +++++++++++++
 fs/xfs/xfs_file.c | 17 +++++++++++------
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 50d3c92709c8..e301d4faf1c3 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -802,10 +802,6 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
 		if (len < EXT4_SB(inode->i_sb)->s_awu_min ||
 		    len > EXT4_SB(inode->i_sb)->s_awu_max)
 			return -EINVAL;
-
-		ret = generic_atomic_write_valid(iocb, from);
-		if (ret)
-			return ret;
 	}
 
 	if (iocb->ki_flags & IOCB_DIRECT)
diff --git a/fs/read_write.c b/fs/read_write.c
index 676728310899..1b34b7382619 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1775,6 +1775,19 @@ ssize_t generic_write_checks(struct kiocb *iocb, struct iov_iter *from)
 	if (ret)
 		return ret;
 
+	/*
+	 * O_APPEND has moved the position and the file size limits have
+	 * shortened the write by now, so this is the range to validate.  An
+	 * atomic write is all or nothing, so refuse it if it got shorter.
+	 */
+	if (iocb->ki_flags & IOCB_ATOMIC) {
+		if (count != iov_iter_count(from))
+			return -EINVAL;
+		ret = generic_atomic_write_valid(iocb, from);
+		if (ret)
+			return ret;
+	}
+
 	iov_iter_truncate(from, count);
 	return iov_iter_count(from);
 }
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index be1f775128d1..153f53f964b9 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -926,12 +926,21 @@ xfs_file_dio_write(
 	if ((iocb->ki_pos | count) & target->bt_logical_sectormask)
 		return -EINVAL;
 
+	/*
+	 * An atomic write is at least one block long, and generic_write_checks()
+	 * refuses it unless its final position is a multiple of its length.  So
+	 * there is no unaligned case to handle for it.
+	 */
+	if (iocb->ki_flags & IOCB_ATOMIC) {
+		if (xfs_is_zoned_inode(ip))
+			return xfs_file_dio_write_zoned(ip, iocb, from);
+		return xfs_file_dio_write_atomic(ip, iocb, from);
+	}
+
 	if ((iocb->ki_pos | count) & ip->i_mount->m_blockmask)
 		return xfs_file_dio_write_unaligned(ip, iocb, from);
 	if (xfs_is_zoned_inode(ip))
 		return xfs_file_dio_write_zoned(ip, iocb, from);
-	if (iocb->ki_flags & IOCB_ATOMIC)
-		return xfs_file_dio_write_atomic(ip, iocb, from);
 	return xfs_file_dio_write_aligned(ip, iocb, from,
 			&xfs_direct_write_iomap_ops, &xfs_dio_write_ops, NULL);
 }
@@ -1128,10 +1137,6 @@ xfs_file_write_iter(
 
 		if (ocount > xfs_get_atomic_write_max(ip))
 			return -EINVAL;
-
-		ret = generic_atomic_write_valid(iocb, from);
-		if (ret)
-			return ret;
 	}
 
 	if (IS_DAX(inode))
-- 
2.55.0

Re: [PATCH v6 05/10] fs: validate atomic writes after O_APPEND and limits

[Carlos Maiolino]

On Mon, Nov 09, 2026 at 06:51:16PM -0500, Chris Mason wrote:
> An RWF_ATOMIC write on XFS with reflink can expose stale disk contents
> if O_APPEND or RLIMIT_FSIZE leaves it sector aligned but not block
> aligned.
> 
> XFS and ext4 call generic_atomic_write_valid() on the range that the
> caller passed. But generic_write_checks() changes the range later:
> O_APPEND moves the position, and RLIMIT_FSIZE cuts the length. XFS can
> then fill only a part of a new block, and still map the whole block into
> the file:
> 
>     block size 4096, i_size 512, O_APPEND
>     validated:        0 to 4095
>     written:          512 to 4607
>     new blocks:       0 to 8191
>     stale below EOF:  0 to 511
> 
> The fix used here is to validate an atomic write in
> generic_write_checks(), after its range is final, and to refuse one that
> was cut. XFS no longer picks the path of an atomic write by the
> alignment of the range that the caller passed.
> 
> Fixes: f096207d3276 ("xfs: Validate atomic writes")
> Fixes: 43c696f9d094 ("ext4: Check for atomic writes support in write iter")
> Signed-off-by: Chris Mason <mason@kernel.org>

Sashiko caught an issue on this patch (and some of the next ones) worth
investigating in depth.

In this one it says it may cause ext4 to silently convert an atomic
write into a buffered non-atomic. I know that ext4 tends to move from
DIO to buffered IO by default, but silently dropping atomic doesn't seem
right in this case.

Looking through the report and the code it indeed seems a valid
possibility in some FS configurations as ext4_dio_alignment checks may
cause ext4_should_use_dio to return false (dio_align == 0 cases).

Giving ext4's special fallback, perhaps just leave the
generic_atomic_write_valid check in place for ext4?


> ---
>  fs/ext4/file.c    |  4 ----
>  fs/read_write.c   | 13 +++++++++++++
>  fs/xfs/xfs_file.c | 17 +++++++++++------
>  3 files changed, 24 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index 50d3c92709c8..e301d4faf1c3 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -802,10 +802,6 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  		if (len < EXT4_SB(inode->i_sb)->s_awu_min ||
>  		    len > EXT4_SB(inode->i_sb)->s_awu_max)
>  			return -EINVAL;
> -
> -		ret = generic_atomic_write_valid(iocb, from);
> -		if (ret)
> -			return ret;
>  	}
>  
>  	if (iocb->ki_flags & IOCB_DIRECT)
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 676728310899..1b34b7382619 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1775,6 +1775,19 @@ ssize_t generic_write_checks(struct kiocb *iocb, struct iov_iter *from)
>  	if (ret)
>  		return ret;
>  
> +	/*
> +	 * O_APPEND has moved the position and the file size limits have
> +	 * shortened the write by now, so this is the range to validate.  An
> +	 * atomic write is all or nothing, so refuse it if it got shorter.
> +	 */
> +	if (iocb->ki_flags & IOCB_ATOMIC) {
> +		if (count != iov_iter_count(from))
> +			return -EINVAL;
> +		ret = generic_atomic_write_valid(iocb, from);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	iov_iter_truncate(from, count);
>  	return iov_iter_count(from);
>  }
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index be1f775128d1..153f53f964b9 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -926,12 +926,21 @@ xfs_file_dio_write(
>  	if ((iocb->ki_pos | count) & target->bt_logical_sectormask)
>  		return -EINVAL;
>  
> +	/*
> +	 * An atomic write is at least one block long, and generic_write_checks()
> +	 * refuses it unless its final position is a multiple of its length.  So
> +	 * there is no unaligned case to handle for it.
> +	 */
> +	if (iocb->ki_flags & IOCB_ATOMIC) {
> +		if (xfs_is_zoned_inode(ip))
> +			return xfs_file_dio_write_zoned(ip, iocb, from);
> +		return xfs_file_dio_write_atomic(ip, iocb, from);
> +	}
> +
>  	if ((iocb->ki_pos | count) & ip->i_mount->m_blockmask)
>  		return xfs_file_dio_write_unaligned(ip, iocb, from);
>  	if (xfs_is_zoned_inode(ip))
>  		return xfs_file_dio_write_zoned(ip, iocb, from);
> -	if (iocb->ki_flags & IOCB_ATOMIC)
> -		return xfs_file_dio_write_atomic(ip, iocb, from);
>  	return xfs_file_dio_write_aligned(ip, iocb, from,
>  			&xfs_direct_write_iomap_ops, &xfs_dio_write_ops, NULL);
>  }
> @@ -1128,10 +1137,6 @@ xfs_file_write_iter(
>  
>  		if (ocount > xfs_get_atomic_write_max(ip))
>  			return -EINVAL;
> -
> -		ret = generic_atomic_write_valid(iocb, from);
> -		if (ret)
> -			return ret;
>  	}
>  
>  	if (IS_DAX(inode))
> -- 
> 2.55.0
> 
> 

Re: [PATCH v6 05/10] fs: validate atomic writes after O_APPEND and limits

[Chris Mason]

On Tue, Nov 10, 2026, at 4:41 AM, Carlos Maiolino wrote:
> On Mon, Nov 09, 2026 at 06:51:16PM -0500, Chris Mason wrote:
>> An RWF_ATOMIC write on XFS with reflink can expose stale disk contents
>> if O_APPEND or RLIMIT_FSIZE leaves it sector aligned but not block
>> aligned.
>> 
>> XFS and ext4 call generic_atomic_write_valid() on the range that the
>> caller passed. But generic_write_checks() changes the range later:
>> O_APPEND moves the position, and RLIMIT_FSIZE cuts the length. XFS can
>> then fill only a part of a new block, and still map the whole block into
>> the file:
>> 
>>     block size 4096, i_size 512, O_APPEND
>>     validated:        0 to 4095
>>     written:          512 to 4607
>>     new blocks:       0 to 8191
>>     stale below EOF:  0 to 511
>> 
>> The fix used here is to validate an atomic write in
>> generic_write_checks(), after its range is final, and to refuse one that
>> was cut. XFS no longer picks the path of an atomic write by the
>> alignment of the range that the caller passed.
>> 
>> Fixes: f096207d3276 ("xfs: Validate atomic writes")
>> Fixes: 43c696f9d094 ("ext4: Check for atomic writes support in write iter")
>> Signed-off-by: Chris Mason <mason@kernel.org>
>
> Sashiko caught an issue on this patch (and some of the next ones) worth
> investigating in depth.
>
> In this one it says it may cause ext4 to silently convert an atomic
> write into a buffered non-atomic. I know that ext4 tends to move from
> DIO to buffered IO by default, but silently dropping atomic doesn't seem
> right in this case.
>
> Looking through the report and the code it indeed seems a valid
> possibility in some FS configurations as ext4_dio_alignment checks may
> cause ext4_should_use_dio to return false (dio_align == 0 cases).
>
> Giving ext4's special fallback, perhaps just leave the
> generic_atomic_write_valid check in place for ext4?

This was actually in the notes and I didn't follow up on it, sorry.

Claude suggests Tal Zussman's (cc'd) patch:

https://lore.kernel.org/all/20261012-ext4-atomic-no-fallback-v2-1-c4b30c60e500@columbia.edu/

Which fixes these cases and is already reviewed by Jan.

Carlos's suggestion also fixes sashiko's bug, but leaves open
the (pre-existing) bug where the offset is ignored in O_APPEND
ATOMIC math.

Last option is to just duplicate Tal's related hunk (below), that's
my least favorite.

Ted?

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 6750d46fe31c..32c789fb2982 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -612,6 +612,9 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from)
 			inode_unlock_shared(inode);
 		else
 			inode_unlock(inode);
+		/* There is no support for atomic writes on buffered-io yet. */
+		if (iocb->ki_flags & IOCB_ATOMIC)
+			return -EOPNOTSUPP;
 		return ext4_buffered_write_iter(iocb, from);
 	}
 

Re: [PATCH v6 05/10] fs: validate atomic writes after O_APPEND and limits

[Carlos Maiolino]

On Tue, Nov 10, 2026 at 10:26:02AM -0500, Chris Mason wrote:
> On Tue, Nov 10, 2026, at 4:41 AM, Carlos Maiolino wrote:
> > On Mon, Nov 09, 2026 at 06:51:16PM -0500, Chris Mason wrote:
> >> An RWF_ATOMIC write on XFS with reflink can expose stale disk contents
> >> if O_APPEND or RLIMIT_FSIZE leaves it sector aligned but not block
> >> aligned.
> >> 
> >> XFS and ext4 call generic_atomic_write_valid() on the range that the
> >> caller passed. But generic_write_checks() changes the range later:
> >> O_APPEND moves the position, and RLIMIT_FSIZE cuts the length. XFS can
> >> then fill only a part of a new block, and still map the whole block into
> >> the file:
> >> 
> >>     block size 4096, i_size 512, O_APPEND
> >>     validated:        0 to 4095
> >>     written:          512 to 4607
> >>     new blocks:       0 to 8191
> >>     stale below EOF:  0 to 511
> >> 
> >> The fix used here is to validate an atomic write in
> >> generic_write_checks(), after its range is final, and to refuse one that
> >> was cut. XFS no longer picks the path of an atomic write by the
> >> alignment of the range that the caller passed.
> >> 
> >> Fixes: f096207d3276 ("xfs: Validate atomic writes")
> >> Fixes: 43c696f9d094 ("ext4: Check for atomic writes support in write iter")
> >> Signed-off-by: Chris Mason <mason@kernel.org>
> >
> > Sashiko caught an issue on this patch (and some of the next ones) worth
> > investigating in depth.
> >
> > In this one it says it may cause ext4 to silently convert an atomic
> > write into a buffered non-atomic. I know that ext4 tends to move from
> > DIO to buffered IO by default, but silently dropping atomic doesn't seem
> > right in this case.
> >
> > Looking through the report and the code it indeed seems a valid
> > possibility in some FS configurations as ext4_dio_alignment checks may
> > cause ext4_should_use_dio to return false (dio_align == 0 cases).
> >
> > Giving ext4's special fallback, perhaps just leave the
> > generic_atomic_write_valid check in place for ext4?
> 
> This was actually in the notes and I didn't follow up on it, sorry.
> 
> Claude suggests Tal Zussman's (cc'd) patch:
> 
> https://lore.kernel.org/all/20261012-ext4-atomic-no-fallback-v2-1-c4b30c60e500@columbia.edu/
> 
> Which fixes these cases and is already reviewed by Jan.

Oh, sorry, I missed that. If that's already reviewed, even better. If we
even have reviews for that... no need to mess up with different
approaches IMHO.

Thanks for the pointer

> 
> Carlos's suggestion also fixes sashiko's bug, but leaves open
> the (pre-existing) bug where the offset is ignored in O_APPEND
> ATOMIC math.
> 
> Last option is to just duplicate Tal's related hunk (below), that's
> my least favorite.
> 
> Ted?
> 
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index 6750d46fe31c..32c789fb2982 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -612,6 +612,9 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  			inode_unlock_shared(inode);
>  		else
>  			inode_unlock(inode);
> +		/* There is no support for atomic writes on buffered-io yet. */
> +		if (iocb->ki_flags & IOCB_ATOMIC)
> +			return -EOPNOTSUPP;
>  		return ext4_buffered_write_iter(iocb, from);
>  	}
>  
> 

[PATCH v6 06/10] xfs: recheck direct write alignment after write checks

[Chris Mason]

A direct write to a reflinked file on XFS can expose stale disk contents
if O_APPEND or RLIMIT_FSIZE leaves it sector aligned but not block
aligned.

A direct write cannot fill only a part of a shared block, so XFS does
such a write through the page cache. xfs_file_dio_write() decides that
from the range that the caller passed. But O_APPEND and RLIMIT_FSIZE
change the range later, in xfs_file_write_checks():

    block size 4096, i_size 4608, O_APPEND, block 1 is shared
    checked:        0 to 4095, block aligned
    written:        4608 to 8703
    new COW block:  4096 to 8191
    never written:  4096 to 4607

The fix used here is to check the alignment again once the range is
final, and to start over on the unaligned path if it no longer holds. A
zoned file now falls back to buffered I/O ahead of that path.

Fixes: 0613f16cd201 ("xfs: implement CoW for directio writes")
Fixes: 3c68d44a2b49 ("xfs: allocate direct I/O COW blocks in iomap_begin")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_file.c | 44 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 153f53f964b9..8ee88910b487 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -710,6 +710,17 @@ xfs_file_dio_write_aligned(
 	if (ret)
 		goto out_unlock;
 
+	/*
+	 * O_APPEND moves the position and the file size limits shorten the
+	 * write, so only now is the range final.  If it is not block aligned,
+	 * this is the wrong path for it.  Return -EAGAIN to
+	 * xfs_file_dio_write(), which picks the path.
+	 */
+	if ((iocb->ki_pos | iov_iter_count(from)) & ip->i_mount->m_blockmask) {
+		ret = -EAGAIN;
+		goto out_unlock;
+	}
+
 	/*
 	 * We don't need to hold the IOLOCK exclusively across the IO, so demote
 	 * the iolock back to shared if we had to take the exclusive lock in
@@ -921,6 +932,7 @@ xfs_file_dio_write(
 	struct xfs_inode	*ip = XFS_I(file_inode(iocb->ki_filp));
 	struct xfs_buftarg      *target = xfs_inode_buftarg(ip);
 	size_t			count = iov_iter_count(from);
+	ssize_t			ret;
 
 	/* direct I/O must be aligned to device logical sector size */
 	if ((iocb->ki_pos | count) & target->bt_logical_sectormask)
@@ -937,12 +949,32 @@ xfs_file_dio_write(
 		return xfs_file_dio_write_atomic(ip, iocb, from);
 	}
 
-	if ((iocb->ki_pos | count) & ip->i_mount->m_blockmask)
-		return xfs_file_dio_write_unaligned(ip, iocb, from);
-	if (xfs_is_zoned_inode(ip))
-		return xfs_file_dio_write_zoned(ip, iocb, from);
-	return xfs_file_dio_write_aligned(ip, iocb, from,
-			&xfs_direct_write_iomap_ops, &xfs_dio_write_ops, NULL);
+	/*
+	 * O_APPEND and the file size limits can still change the range, in
+	 * xfs_file_write_checks().  So a range that is block aligned here may
+	 * not stay so, and the write then comes back with -EAGAIN.  If we are
+	 * doing nonblocking user I/O, propagate the error.
+	 */
+	if (!((iocb->ki_pos | count) & ip->i_mount->m_blockmask)) {
+		if (xfs_is_zoned_inode(ip))
+			ret = xfs_file_dio_write_zoned(ip, iocb, from);
+		else
+			ret = xfs_file_dio_write_aligned(ip, iocb, from,
+					&xfs_direct_write_iomap_ops,
+					&xfs_dio_write_ops, NULL);
+		if (ret != -EAGAIN || (iocb->ki_flags & IOCB_NOWAIT))
+			return ret;
+	}
+
+	/*
+	 * Zoned inodes always write out of place, which does not work for a
+	 * part of a block.  Fall back to buffered I/O.
+	 */
+	if (xfs_is_zoned_inode(ip)) {
+		trace_xfs_reflink_bounce_dio_write(iocb, from);
+		return -ENOTBLK;
+	}
+	return xfs_file_dio_write_unaligned(ip, iocb, from);
 }
 
 static noinline ssize_t
-- 
2.55.0

[PATCH v6 07/10] xfs: test for reflink after the dio write checks

[Chris Mason]

A direct write that is not block aligned can expose stale disk contents
on XFS if it races with the first clone of the file.

xfs_file_dio_write_unaligned() falls back to buffered I/O if the file is
reflinked, and tests for that right after it takes the iolock. But
xfs_file_write_checks() runs after the test and can drop the iolock, for
example if S_NOSEC is not set. A clone can run in that gap:

    direct write                        clone
    ============                        =====
    takes the iolock shared
    sees that the file is not reflinked
    drops the iolock
                                        shares the blocks
    takes the iolock exclusive
    writes a part of a new COW block
    maps the whole block into the file
      /* the rest was never written */

The fix used here is to move the test after xfs_file_write_checks().

Fixes: ed1128c2d0c8 ("xfs: reduce exclusive locking on unaligned dio")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_file.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 8ee88910b487..d888470d092a 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -877,9 +877,15 @@ xfs_file_dio_write_unaligned(
 	if (ret)
 		return ret;
 
+	ret = xfs_file_write_checks(iocb, from, &iolock, NULL);
+	if (ret)
+		goto out_unlock;
+
 	/*
 	 * We can't properly handle unaligned direct I/O to reflink files yet,
-	 * as we can't unshare a partial block.
+	 * as we can't unshare a partial block.  xfs_file_write_checks() can
+	 * drop the iolock and take it again, and the file can be reflinked in
+	 * between, so test for that only now.
 	 */
 	if (xfs_is_cow_inode(ip)) {
 		trace_xfs_reflink_bounce_dio_write(iocb, from);
@@ -887,10 +893,6 @@ xfs_file_dio_write_unaligned(
 		goto out_unlock;
 	}
 
-	ret = xfs_file_write_checks(iocb, from, &iolock, NULL);
-	if (ret)
-		goto out_unlock;
-
 	/*
 	 * If we are doing exclusive unaligned I/O, this must be the only I/O
 	 * in-flight.  Otherwise we risk data corruption due to unwritten extent
-- 
2.55.0

[PATCH v6 08/10] xfs: refuse writes to files racing with realtime inode flag changes

[Chris Mason]

From: Christoph Hellwig <hch@lst.de>

Zoned writes need to reserve space before taking the iolock to avoid
deadlocks with garbage collection.  But this means that the realtime inode
flag which indicates if the file will be placed on the zoned realtime
device or the main data device can be flipped after taking the reservation
and before taking the write, or after deciding to go down the regular
write path, both of which can't work.

Re-sample the realtime flag just before the actual write, and refuse the
write if the flag changed.  Do not retry the write using the now correct
path, as switching the flag under a write is not a normal use case, and
trying to flip between the zoned and regular path is an inherent life
lock as it could be switched around again the next time this check is
performed.

Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices")
Fixes: 2e2383405824 ("xfs: implement direct writes to zoned RT devices")
Reported-by: Chris Mason <mason@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
---
 fs/xfs/xfs_file.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index d888470d092a..515ddafc6673 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -441,6 +441,19 @@ xfs_file_write_checks(
 		goto restart;
 	}

+	/*
+	 * Now that we are in the same IOLOCK critical section as the actual
+	 * write, check that the inode still has the realtime flag in the state
+	 * that the caller expects.  If not, some deliberately cleared it while
+	 * I/O is ongoing, so bail out.
+	 */
+	if (xfs_is_zoned_inode(XFS_I(inode)) != !!ac) {
+		xfs_warn_ratelimited(XFS_I(inode)->i_mount,
+			"RT flag modifying during write for inode 0x%llx.",
+			inode->i_ino);
+		return -EINVAL;
+	}
+
 	/*
 	 * If the offset is beyond the size of the file, we need to zero all
 	 * blocks that fall between the existing EOF and the start of this
--
2.55.0

[PATCH v6 09/10] xfs: refuse fallocate racing with realtime flag changes

[Chris Mason]

On a zoned XFS, fallocate() can dereference a NULL pointer if the
realtime flag of the file is set during the call.

xfs_file_fallocate() reserves zoned space only for a zoned inode, and
tests for that before it takes the iolock. FS_IOC_FSSETXATTR can change
the realtime flag of a file with no blocks in that gap.
xfs_falloc_force_zero() then sees a zoned inode and reads the
reservation, which is NULL:

    fallocate(FALLOC_FL_ZERO_RANGE)     FS_IOC_FSSETXATTR
    ===============================     =================
                                        takes the iolock
    sees that the inode is not zoned
    waits for the iolock
                                        sets the realtime flag
                                        drops the iolock
    xfs_falloc_force_zero()
      sees that the inode is zoned
      /* ac is NULL */

The fix used here is to test again under the iolock, and to fail the
call with -EINVAL if the answer has changed, as the write path does.

Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_file.c | 41 ++++++++++++++++++++++++++++++++---------
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 515ddafc6673..26967ca4f3fb 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1572,6 +1572,21 @@ xfs_falloc_allocate_range(
 		 FALLOC_FL_ZERO_RANGE |	FALLOC_FL_INSERT_RANGE |	\
 		 FALLOC_FL_UNSHARE_RANGE | FALLOC_FL_WRITE_ZEROES)

+/*
+ * For zoned file systems, zeroing the first and last block of a hole punch
+ * requires allocating a new block to rewrite the remaining data and new zeroes
+ * out of place, which needs a space reservation.
+ */
+static inline bool
+xfs_falloc_needs_zoned_resv(
+	struct xfs_inode	*ip,
+	int			mode)
+{
+	return xfs_is_zoned_inode(ip) &&
+		(mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_ZERO_RANGE |
+			 FALLOC_FL_COLLAPSE_RANGE));
+}
+
 STATIC long
 __xfs_file_fallocate(
 	struct file		*file,
@@ -1590,6 +1605,19 @@ __xfs_file_fallocate(
 	if (error)
 		goto out_unlock;

+	/*
+	 * The caller looked at the realtime flag before we took the IOLOCK, to
+	 * decide if it has to reserve space.  Bail out if the flag has changed
+	 * since.
+	 */
+	if (xfs_falloc_needs_zoned_resv(ip, mode) != !!ac) {
+		xfs_warn_ratelimited(ip->i_mount,
+			"RT flag modifying during fallocate for inode 0x%llx.",
+			inode->i_ino);
+		error = -EINVAL;
+		goto out_unlock;
+	}
+
 	/*
 	 * Must wait for all AIO to complete before we continue as AIO can
 	 * change the file size on completion without holding any locks we
@@ -1685,16 +1713,11 @@ xfs_file_fallocate(
 		return -EOPNOTSUPP;

 	/*
-	 * For zoned file systems, zeroing the first and last block of a hole
-	 * punch requires allocating a new block to rewrite the remaining data
-	 * and new zeroes out of place.  Get a reservations for those before
-	 * taking the iolock.  Dip into the reserved pool because we are
-	 * expected to be able to punch a hole even on a completely full
-	 * file system.
+	 * Get the reservation before taking the iolock.  Dip into the reserved
+	 * pool because we are expected to be able to punch a hole even on a
+	 * completely full file system.
 	 */
-	if (xfs_is_zoned_inode(XFS_I(inode)) &&
-	    (mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_ZERO_RANGE |
-		     FALLOC_FL_COLLAPSE_RANGE)))
+	if (xfs_falloc_needs_zoned_resv(XFS_I(inode), mode))
 		return xfs_file_zoned_fallocate(file, mode, offset, len);
 	return __xfs_file_fallocate(file, mode, offset, len, NULL);
 }
--
2.55.0

[PATCH v6 10/10] xfs: restart faults racing with realtime flag changes

[Chris Mason]

On a zoned XFS, a store through a shared mapping can dereference a NULL
pointer, or corrupt the free block counter, if the realtime flag of the
file changes during the write fault.

xfs_write_fault() reserves zoned space only for a zoned inode, and tests
for that with no lock held. xfs_buffered_write_iomap_begin() tests again
before it takes the ILOCK. FS_IOC_FSSETXATTR can change the flag of a
file with no blocks between the two tests, since a fault never takes the
IOLOCK:

    write fault                           FS_IOC_FSSETXATTR
    ===========                           =================
    xfs_write_fault()
      sees that the inode is not zoned
                                          sets the realtime flag
    xfs_buffered_write_iomap_begin()
      sees that the inode is zoned
      /* ac is NULL */

If the flag is cleared instead, xfs_zoned_buffered_write_iomap_begin()
can be waiting for the ILOCK at that time. It then reserves blocks the
zoned way on a regular inode, and the free block counter ends up too
high.

The fix used here is to test again under the ILOCK, before blocks are
reserved or allocated, and to return -EAGAIN if the flag has changed, so
that the fault starts over.

Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices")
Signed-off-by: Chris Mason <mason@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_iomap.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index c3465204b8d5..3e71d619c657 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -264,6 +264,23 @@ xfs_iomap_eof_align_last_fsb(
 	return end_fsb;
 }

+/*
+ * A write fault picks the zoned or the regular path before it takes a lock, and
+ * it never takes the IOLOCK, which keeps the realtime flag stable for all other
+ * callers.  The flag cannot change under the ILOCK, or once the inode has
+ * blocks.  So look at it again under the ILOCK, before reserving or allocating
+ * blocks, and make the fault start over if it has changed.
+ */
+static int
+xfs_iomap_rtflag_changed(
+	struct xfs_inode	*ip)
+{
+	xfs_warn_ratelimited(ip->i_mount,
+		"RT flag modifying during page fault for inode 0x%llx.",
+		VFS_I(ip)->i_ino);
+	return -EAGAIN;
+}
+
 int
 xfs_iomap_write_direct(
 	struct xfs_inode	*ip,
@@ -334,6 +351,11 @@ xfs_iomap_write_direct(
 	if (error)
 		return error;

+	if (xfs_is_zoned_inode(ip)) {
+		error = xfs_iomap_rtflag_changed(ip);
+		goto out_trans_cancel;
+	}
+
 	error = xfs_iext_count_extend(tp, ip, XFS_DATA_FORK, nr_exts);
 	if (error)
 		goto out_trans_cancel;
@@ -1668,7 +1690,6 @@ xfs_zoned_buffered_write_iomap_begin(

 	ASSERT(!xfs_get_extsz_hint(ip));
 	ASSERT(!(flags & IOMAP_UNSHARE));
-	ASSERT(ac);

 	if (xfs_is_shutdown(mp))
 		return -EIO;
@@ -1682,6 +1703,11 @@ xfs_zoned_buffered_write_iomap_begin(
 	if (error)
 		return error;

+	if (!xfs_is_zoned_inode(ip) || !ac) {
+		error = xfs_iomap_rtflag_changed(ip);
+		goto out_unlock;
+	}
+
 	if (XFS_IS_CORRUPT(mp, !xfs_ifork_has_extents(&ip->i_df)) ||
 	    XFS_TEST_ERROR(mp, XFS_ERRTAG_BMAPIFORMAT)) {
 		xfs_bmap_mark_sick(ip, XFS_DATA_FORK);
@@ -1865,6 +1891,11 @@ xfs_buffered_write_iomap_begin(
 	if (error)
 		return error;

+	if (xfs_is_zoned_inode(ip)) {
+		error = xfs_iomap_rtflag_changed(ip);
+		goto out_unlock;
+	}
+
 	if (XFS_IS_CORRUPT(mp, !xfs_ifork_has_extents(&ip->i_df)) ||
 	    XFS_TEST_ERROR(mp, XFS_ERRTAG_BMAPIFORMAT)) {
 		xfs_bmap_mark_sick(ip, XFS_DATA_FORK);
--
2.55.0

Re: [PATCH v6 00/10] reflink and atomic write bugs

[Carlos Maiolino]

On Mon, Nov 09, 2026 at 06:51:11PM -0500, Chris Mason wrote:
> Hi everyone,
> 
> This series did a few rounds privately, but looks ready for the list
> now.  Except for Christoph's patch, these were all found and fixed
> by an LLM.
> 
> The meat of the series is fixing reflink corner cases that incorrectly
> let you write into the source of a reflink.  LLMs also tripped over a
> few ways to use atomic writes to expose stale blocks on the drive, and a
> few races with realtime flag manipulations.
> 
> Carlos and Christoph ran these through fstests (thanks guys).
> 
> Chris Mason (9):
>   xfs: don't skip the flush before shifting extents
>   xfs: flush the shifted range before changing the file
>   xfs: don't change the block map under a dirty folio
>   iomap: don't punch delalloc under a dirty EOF block
>   fs: validate atomic writes after O_APPEND and limits
>   xfs: recheck direct write alignment after write checks
>   xfs: test for reflink after the dio write checks
>   xfs: refuse fallocate racing with realtime flag changes
>   xfs: restart faults racing with realtime flag changes
> 
> Christoph Hellwig (1):
>   xfs: refuse writes to files racing with realtime inode flag changes

Sashiko found a few issues that I believe are worth looking at. If there
are no objections though, I'll pull in the first 4 patches which are the
most critical ones so far until we figure out the other ones. If there
are objections please let me know and I'll revert them back.


> 
>  fs/ext4/file.c         |   4 --
>  fs/iomap/buffered-io.c |  34 ++++++++--
>  fs/read_write.c        |  13 ++++
>  fs/xfs/xfs_bmap_util.c |  19 +++++-
>  fs/xfs/xfs_file.c      | 150 +++++++++++++++++++++++++++++++++--------
>  fs/xfs/xfs_iomap.c     |  33 ++++++++-
>  fs/xfs/xfs_reflink.c   |   2 +-
>  7 files changed, 215 insertions(+), 40 deletions(-)
> 
> 
> base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
> --
> 2.55.0
> 
> 

Re: [PATCH v6 00/10] reflink and atomic write bugs

[Chris Mason]

On Tue, Nov 10, 2026, at 4:45 AM, Carlos Maiolino wrote:
> On Mon, Nov 09, 2026 at 06:51:11PM -0500, Chris Mason wrote:
>> Hi everyone,
>> 
>> This series did a few rounds privately, but looks ready for the list
>> now.  Except for Christoph's patch, these were all found and fixed
>> by an LLM.
>> 
>> The meat of the series is fixing reflink corner cases that incorrectly
>> let you write into the source of a reflink.  LLMs also tripped over a
>> few ways to use atomic writes to expose stale blocks on the drive, and a
>> few races with realtime flag manipulations.
>> 
>> Carlos and Christoph ran these through fstests (thanks guys).
>> 
>> Chris Mason (9):
>>   xfs: don't skip the flush before shifting extents
>>   xfs: flush the shifted range before changing the file
>>   xfs: don't change the block map under a dirty folio
>>   iomap: don't punch delalloc under a dirty EOF block
>>   fs: validate atomic writes after O_APPEND and limits
>>   xfs: recheck direct write alignment after write checks
>>   xfs: test for reflink after the dio write checks
>>   xfs: refuse fallocate racing with realtime flag changes
>>   xfs: restart faults racing with realtime flag changes
>> 
>> Christoph Hellwig (1):
>>   xfs: refuse writes to files racing with realtime inode flag changes
>
> Sashiko found a few issues that I believe are worth looking at. If there
> are no objections though, I'll pull in the first 4 patches which are the
> most critical ones so far until we figure out the other ones. If there
> are objections please let me know and I'll revert them back.

I'm generating fixes for the rest of sashiko's comments.  Looks like they
all existed before the series, but might as well fix them while we're here.

For sashiko's complaint about patch 6, the patch intentionally creates
the behavior sashiko mentioned.  We were inconsistently falling back
to buffered before so the behavior is new but the writes are correct.

-chris

Re: [PATCH v6 00/10] reflink and atomic write bugs

[Carlos Maiolino]

On Tue, Nov 10, 2026 at 10:56:34AM -0500, Chris Mason wrote:
> On Tue, Nov 10, 2026, at 4:45 AM, Carlos Maiolino wrote:
> > On Mon, Nov 09, 2026 at 06:51:11PM -0500, Chris Mason wrote:
> >> Hi everyone,
> >> 
> >> This series did a few rounds privately, but looks ready for the list
> >> now.  Except for Christoph's patch, these were all found and fixed
> >> by an LLM.
> >> 
> >> The meat of the series is fixing reflink corner cases that incorrectly
> >> let you write into the source of a reflink.  LLMs also tripped over a
> >> few ways to use atomic writes to expose stale blocks on the drive, and a
> >> few races with realtime flag manipulations.
> >> 
> >> Carlos and Christoph ran these through fstests (thanks guys).
> >> 
> >> Chris Mason (9):
> >>   xfs: don't skip the flush before shifting extents
> >>   xfs: flush the shifted range before changing the file
> >>   xfs: don't change the block map under a dirty folio
> >>   iomap: don't punch delalloc under a dirty EOF block
> >>   fs: validate atomic writes after O_APPEND and limits
> >>   xfs: recheck direct write alignment after write checks
> >>   xfs: test for reflink after the dio write checks
> >>   xfs: refuse fallocate racing with realtime flag changes
> >>   xfs: restart faults racing with realtime flag changes
> >> 
> >> Christoph Hellwig (1):
> >>   xfs: refuse writes to files racing with realtime inode flag changes
> >
> > Sashiko found a few issues that I believe are worth looking at. If there
> > are no objections though, I'll pull in the first 4 patches which are the
> > most critical ones so far until we figure out the other ones. If there
> > are objections please let me know and I'll revert them back.
> 
> I'm generating fixes for the rest of sashiko's comments.  Looks like they
> all existed before the series, but might as well fix them while we're here.
> 
> For sashiko's complaint about patch 6, the patch intentionally creates
> the behavior sashiko mentioned.  We were inconsistently falling back
> to buffered before so the behavior is new but the writes are correct.

FWIW, I pushed the initial 4 patches to xfs-linux/xfs-7.4-fixes, of
course I didn't push them yet to for-next as it depends on you if you
are ok with me pulling them first before you deal with Sashiko failures.


> 
> -chris
> 

Re: [PATCH v6 00/10] reflink and atomic write bugs

[Chris Mason]

On Tue, Nov 10, 2026, at 11:22 AM, Carlos Maiolino wrote:
> On Tue, Nov 10, 2026 at 10:56:34AM -0500, Chris Mason wrote:
>> On Tue, Nov 10, 2026, at 4:45 AM, Carlos Maiolino wrote:
>> > On Mon, Nov 09, 2026 at 06:51:11PM -0500, Chris Mason wrote:
>> >> Hi everyone,
>> >> 
>> >> This series did a few rounds privately, but looks ready for the list
>> >> now.  Except for Christoph's patch, these were all found and fixed
>> >> by an LLM.
>> >> 
>> >> The meat of the series is fixing reflink corner cases that incorrectly
>> >> let you write into the source of a reflink.  LLMs also tripped over a
>> >> few ways to use atomic writes to expose stale blocks on the drive, and a
>> >> few races with realtime flag manipulations.
>> >> 
>> >> Carlos and Christoph ran these through fstests (thanks guys).
>> >> 
>> >> Chris Mason (9):
>> >>   xfs: don't skip the flush before shifting extents
>> >>   xfs: flush the shifted range before changing the file
>> >>   xfs: don't change the block map under a dirty folio
>> >>   iomap: don't punch delalloc under a dirty EOF block
>> >>   fs: validate atomic writes after O_APPEND and limits
>> >>   xfs: recheck direct write alignment after write checks
>> >>   xfs: test for reflink after the dio write checks
>> >>   xfs: refuse fallocate racing with realtime flag changes
>> >>   xfs: restart faults racing with realtime flag changes
>> >> 
>> >> Christoph Hellwig (1):
>> >>   xfs: refuse writes to files racing with realtime inode flag changes
>> >
>> > Sashiko found a few issues that I believe are worth looking at. If there
>> > are no objections though, I'll pull in the first 4 patches which are the
>> > most critical ones so far until we figure out the other ones. If there
>> > are objections please let me know and I'll revert them back.
>> 
>> I'm generating fixes for the rest of sashiko's comments.  Looks like they
>> all existed before the series, but might as well fix them while we're here.
>> 
>> For sashiko's complaint about patch 6, the patch intentionally creates
>> the behavior sashiko mentioned.  We were inconsistently falling back
>> to buffered before so the behavior is new but the writes are correct.
>
> FWIW, I pushed the initial 4 patches to xfs-linux/xfs-7.4-fixes, of
> course I didn't push them yet to for-next as it depends on you if you
> are ok with me pulling them first before you deal with Sashiko failures.

Thanks, taking the first 4 for now works for me.  I'll keep them unchanged
in the next version just so things keep applying, but will assume they are
all set.

-chris

Re: [PATCH v6 00/10] reflink and atomic write bugs

[Carlos Maiolino]

On Tue, Nov 10, 2026 at 11:32:51AM -0500, Chris Mason wrote:
> On Tue, Nov 10, 2026, at 11:22 AM, Carlos Maiolino wrote:
> > On Tue, Nov 10, 2026 at 10:56:34AM -0500, Chris Mason wrote:
> >> On Tue, Nov 10, 2026, at 4:45 AM, Carlos Maiolino wrote:
> >> > On Mon, Nov 09, 2026 at 06:51:11PM -0500, Chris Mason wrote:
> >> >> Hi everyone,
> >> >> 
> >> >> This series did a few rounds privately, but looks ready for the list
> >> >> now.  Except for Christoph's patch, these were all found and fixed
> >> >> by an LLM.
> >> >> 
> >> >> The meat of the series is fixing reflink corner cases that incorrectly
> >> >> let you write into the source of a reflink.  LLMs also tripped over a
> >> >> few ways to use atomic writes to expose stale blocks on the drive, and a
> >> >> few races with realtime flag manipulations.
> >> >> 
> >> >> Carlos and Christoph ran these through fstests (thanks guys).
> >> >> 
> >> >> Chris Mason (9):
> >> >>   xfs: don't skip the flush before shifting extents
> >> >>   xfs: flush the shifted range before changing the file
> >> >>   xfs: don't change the block map under a dirty folio
> >> >>   iomap: don't punch delalloc under a dirty EOF block
> >> >>   fs: validate atomic writes after O_APPEND and limits
> >> >>   xfs: recheck direct write alignment after write checks
> >> >>   xfs: test for reflink after the dio write checks
> >> >>   xfs: refuse fallocate racing with realtime flag changes
> >> >>   xfs: restart faults racing with realtime flag changes
> >> >> 
> >> >> Christoph Hellwig (1):
> >> >>   xfs: refuse writes to files racing with realtime inode flag changes
> >> >
> >> > Sashiko found a few issues that I believe are worth looking at. If there
> >> > are no objections though, I'll pull in the first 4 patches which are the
> >> > most critical ones so far until we figure out the other ones. If there
> >> > are objections please let me know and I'll revert them back.
> >> 
> >> I'm generating fixes for the rest of sashiko's comments.  Looks like they
> >> all existed before the series, but might as well fix them while we're here.
> >> 
> >> For sashiko's complaint about patch 6, the patch intentionally creates
> >> the behavior sashiko mentioned.  We were inconsistently falling back
> >> to buffered before so the behavior is new but the writes are correct.
> >
> > FWIW, I pushed the initial 4 patches to xfs-linux/xfs-7.4-fixes, of
> > course I didn't push them yet to for-next as it depends on you if you
> > are ok with me pulling them first before you deal with Sashiko failures.
> 
> Thanks, taking the first 4 for now works for me.  I'll keep them unchanged
> in the next version just so things keep applying, but will assume they are
> all set.

Sounds good :)

> 
> -chris
>