[PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Qu Wenruo]

[BUG]
On the latest development branch, btrfs with 8K block size on 4K page
sized systems will fail all test cases that run fsstress.

One very short example would be:

 # $fsstress -n 4 -d $mnt -s 1785675805 -v
 0/0: dwrite - no filename
 0/1: creat f0 x:0 0 0
 0/1: creat add id=0,parent=-1
 0/2: write dontcache f0[259 1 0 0 0 0] [816411,3620] 0
 0/3: dread - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 32 820031] return 25, fallback to stat()
 0/3: dread f0[259 1 0 0 32 820031] [483328,81920] 0

Which triggered the following ASSERT():

 assertion failed: IS_ALIGNED(state->start, blocksize) && IS_ALIGNED(state->end + 1, blocksize), in fs/btrfs/extent-io-tree.c:346 (unaligned extent state, blocksize=8192 start=487424 end=565247 state=0x0)
 ------------[ cut here ]------------
 kernel BUG at fs/btrfs/extent-io-tree.c:346!
 Oops: invalid opcode: 0000 [#1] SMP
 CPU: 4 UID: 0 PID: 648 Comm: fsstress Tainted: G            E       7.2.0-rc5-custom+ #431 PREEMPT(full)  7c507bd40d65e4d871e698b22d80f1306bbec543
 Tainted: [E]=UNSIGNED_MODULE
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
 RIP: 0010:validate_extent_state.part.0.isra.0.cold+0x24/0x26 [btrfs]
 Call Trace:
  <TASK>
  insert_state+0x34/0x1a0 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  set_extent_bit+0x440/0x8d0 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  btrfs_lock_extent_bits+0x58/0x380 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  btrfs_dio_iomap_begin+0x319/0xb70 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  iomap_iter+0x1a2/0x370
  __iomap_dio_rw+0x236/0x8d0
  iomap_dio_rw+0x12/0x30
  btrfs_direct_read+0x15f/0x290 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  btrfs_file_read_iter+0x42/0x90 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
  vfs_read+0x25e/0x380
  ksys_read+0x73/0xe0
  do_syscall_64+0xe1/0x790
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7fc3f129318e
  </TASK>

[CAUSE]
iomap_dio_hole_iter() is responsible for zeroing out the buffer for a
hole, which calls iov_iter_zero() to zero the range.

However btrfs disables page fault during its __iomap_dio_rw() call, so
iov_iter_zero() can fail at any page boundary.

When the fs block size is larger than page size, iov_iter_zero() may
only have zeroed one page, which is not aligned to the fs block size.

Such one page long range is passed back to btrfs, which triggers the
above ASSERT().

[FIX]
For iomap_dio_hole_iter() round down the copied length, and revert
any excessive range that is beyond the aligned copied length.
Also use @aligned_copied for the size increment and iter advancement.

This should only affect btrfs, which is the only fs utilizing iomap dio
with page fault disabled.

Fixes: 001397f5ef49 ("iomap: add IOMAP_DIO_FSBLOCK_ALIGNED flag")
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
v4:
- Always align down to fs block size

v3:
- Fix a NULL pointer dereference where @bdev can be NULL for holes

v2:
- Rebased to the latest vfs tree

- Slightly rewords the reproducer
  In fact no special reproducer needed, any test case running fsstress
  can easily trigger it.

  The example provided is just the shortest sequence I used to debug the
  crash.
---
 fs/iomap/direct-io.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index b3368d64e81b..01f26fb3b3b2 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -594,12 +594,19 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio)
 
 static int iomap_dio_hole_iter(struct iomap_iter *iter, struct iomap_dio *dio)
 {
-	loff_t length = iov_iter_zero(iomap_length(iter), dio->submit.iter);
+	loff_t copied = iov_iter_zero(iomap_length(iter), dio->submit.iter);
+	unsigned int bs = i_blocksize(iter->inode);
+	loff_t aligned_copied = round_down(copied, bs);
 
-	dio->size += length;
-	if (!length)
+	/*
+	 * If fs block size is larger than page size, page fault failure
+	 * can cause @copied to be page aligned but not fs block aligned.
+	 */
+	iov_iter_revert(dio->submit.iter, copied - aligned_copied);
+	dio->size += aligned_copied;
+	if (!aligned_copied)
 		return -EFAULT;
-	return iomap_iter_advance(iter, length);
+	return iomap_iter_advance(iter, aligned_copied);
 }
 
 static int iomap_dio_inline_iter(struct iomap_iter *iomi, struct iomap_dio *dio)
-- 
2.54.0

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Pankaj Raghav (Samsung)]

> [FIX]
> For iomap_dio_hole_iter() round down the copied length, and revert
> any excessive range that is beyond the aligned copied length.
> Also use @aligned_copied for the size increment and iter advancement.
> 
> This should only affect btrfs, which is the only fs utilizing iomap dio
> with page fault disabled.
> 
> Fixes: 001397f5ef49 ("iomap: add IOMAP_DIO_FSBLOCK_ALIGNED flag")
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Looks good,
Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>
-- 
Pankaj

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Qu Wenruo]

Gentle ping?

This patch has multiple reviewed-by tags, but I still didn't see it in 
the upstream rc1 nor vfs.all branch.

Thanks,
Qu

在 2026/8/5 07:29, Qu Wenruo 写道:
> [BUG]
> On the latest development branch, btrfs with 8K block size on 4K page
> sized systems will fail all test cases that run fsstress.
> 
> One very short example would be:
> 
>   # $fsstress -n 4 -d $mnt -s 1785675805 -v
>   0/0: dwrite - no filename
>   0/1: creat f0 x:0 0 0
>   0/1: creat add id=0,parent=-1
>   0/2: write dontcache f0[259 1 0 0 0 0] [816411,3620] 0
>   0/3: dread - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 32 820031] return 25, fallback to stat()
>   0/3: dread f0[259 1 0 0 32 820031] [483328,81920] 0
> 
> Which triggered the following ASSERT():
> 
>   assertion failed: IS_ALIGNED(state->start, blocksize) && IS_ALIGNED(state->end + 1, blocksize), in fs/btrfs/extent-io-tree.c:346 (unaligned extent state, blocksize=8192 start=487424 end=565247 state=0x0)
>   ------------[ cut here ]------------
>   kernel BUG at fs/btrfs/extent-io-tree.c:346!
>   Oops: invalid opcode: 0000 [#1] SMP
>   CPU: 4 UID: 0 PID: 648 Comm: fsstress Tainted: G            E       7.2.0-rc5-custom+ #431 PREEMPT(full)  7c507bd40d65e4d871e698b22d80f1306bbec543
>   Tainted: [E]=UNSIGNED_MODULE
>   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
>   RIP: 0010:validate_extent_state.part.0.isra.0.cold+0x24/0x26 [btrfs]
>   Call Trace:
>    <TASK>
>    insert_state+0x34/0x1a0 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    set_extent_bit+0x440/0x8d0 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    btrfs_lock_extent_bits+0x58/0x380 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    btrfs_dio_iomap_begin+0x319/0xb70 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    iomap_iter+0x1a2/0x370
>    __iomap_dio_rw+0x236/0x8d0
>    iomap_dio_rw+0x12/0x30
>    btrfs_direct_read+0x15f/0x290 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    btrfs_file_read_iter+0x42/0x90 [btrfs 6924944583e4bc91a7c5183a1e7908e745a9b0c8]
>    vfs_read+0x25e/0x380
>    ksys_read+0x73/0xe0
>    do_syscall_64+0xe1/0x790
>    entry_SYSCALL_64_after_hwframe+0x4b/0x53
>   RIP: 0033:0x7fc3f129318e
>    </TASK>
> 
> [CAUSE]
> iomap_dio_hole_iter() is responsible for zeroing out the buffer for a
> hole, which calls iov_iter_zero() to zero the range.
> 
> However btrfs disables page fault during its __iomap_dio_rw() call, so
> iov_iter_zero() can fail at any page boundary.
> 
> When the fs block size is larger than page size, iov_iter_zero() may
> only have zeroed one page, which is not aligned to the fs block size.
> 
> Such one page long range is passed back to btrfs, which triggers the
> above ASSERT().
> 
> [FIX]
> For iomap_dio_hole_iter() round down the copied length, and revert
> any excessive range that is beyond the aligned copied length.
> Also use @aligned_copied for the size increment and iter advancement.
> 
> This should only affect btrfs, which is the only fs utilizing iomap dio
> with page fault disabled.
> 
> Fixes: 001397f5ef49 ("iomap: add IOMAP_DIO_FSBLOCK_ALIGNED flag")
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> v4:
> - Always align down to fs block size
> 
> v3:
> - Fix a NULL pointer dereference where @bdev can be NULL for holes
> 
> v2:
> - Rebased to the latest vfs tree
> 
> - Slightly rewords the reproducer
>    In fact no special reproducer needed, any test case running fsstress
>    can easily trigger it.
> 
>    The example provided is just the shortest sequence I used to debug the
>    crash.
> ---
>   fs/iomap/direct-io.c | 15 +++++++++++----
>   1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index b3368d64e81b..01f26fb3b3b2 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -594,12 +594,19 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio)
>   
>   static int iomap_dio_hole_iter(struct iomap_iter *iter, struct iomap_dio *dio)
>   {
> -	loff_t length = iov_iter_zero(iomap_length(iter), dio->submit.iter);
> +	loff_t copied = iov_iter_zero(iomap_length(iter), dio->submit.iter);
> +	unsigned int bs = i_blocksize(iter->inode);
> +	loff_t aligned_copied = round_down(copied, bs);
>   
> -	dio->size += length;
> -	if (!length)
> +	/*
> +	 * If fs block size is larger than page size, page fault failure
> +	 * can cause @copied to be page aligned but not fs block aligned.
> +	 */
> +	iov_iter_revert(dio->submit.iter, copied - aligned_copied);
> +	dio->size += aligned_copied;
> +	if (!aligned_copied)
>   		return -EFAULT;
> -	return iomap_iter_advance(iter, length);
> +	return iomap_iter_advance(iter, aligned_copied);
>   }
>   
>   static int iomap_dio_inline_iter(struct iomap_iter *iomi, struct iomap_dio *dio)

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Christian Brauner]

On Wed, 05 Aug 2026 07:29:51 +0930, Qu Wenruo wrote:
> [BUG]
> On the latest development branch, btrfs with 8K block size on 4K page
> sized systems will fail all test cases that run fsstress.
> 
> One very short example would be:
> 
>  # $fsstress -n 4 -d $mnt -s 1785675805 -v
>  0/0: dwrite - no filename
>  0/1: creat f0 x:0 0 0
>  0/1: creat add id=0,parent=-1
>  0/2: write dontcache f0[259 1 0 0 0 0] [816411,3620] 0
>  0/3: dread - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 32 820031] return 25, fallback to stat()
>  0/3: dread f0[259 1 0 0 32 820031] [483328,81920] 0
> 
> [...]

Applied to the vfs-7.4.iomap branch of the vfs/vfs.git tree.
Patches in the vfs-7.4.iomap branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.4.iomap

[1/1] iomap: follow the alignment requirement for iomap_dio_hole_iter()
      https://git.kernel.org/vfs/vfs/c/c156c9afe59b

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[kernel test robot]

Hello,

kernel test robot noticed "xfstests.generic.091.fail" on:

commit: 4025185cf953e3f52ab63cf5fec50c1485ee7bb7 ("[PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master patch link: https://lore.kernel.org/all/73bd4d9b39e821453028ca8e567eaad2ebe0fc18.1785880740.git.wqu@suse.com/
patch subject: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[test failed on linux-next/master 20a33c6b6cbe7e4805dfb6cd68816937443aa148]

in testcase: xfstests
version: xfstests-x86_64-22348afe-1_20261019
with following parameters:

	disk: 4HDD
	fs: ext4
	test: generic-group-09


config: x86_64-rhel-9.4-func
compiler: gcc-14
test machine: 8 threads Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Skylake) with 28G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)


If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <yi1.lai@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202610261048.3dc64aea-lkp@intel.com


2026-10-24 23:20:06 cd /lkp/benchmarks/xfstests
2026-10-24 23:20:07 export TEST_DIR=/fs/sda1
2026-10-24 23:20:07 export TEST_DEV=/dev/sda1
2026-10-24 23:20:07 export FSTYP=ext4
2026-10-24 23:20:07 export SCRATCH_MNT=/fs/scratch
2026-10-24 23:20:07 mkdir /fs/scratch -p
2026-10-24 23:20:07 export SCRATCH_DEV=/dev/sda4
2026-10-24 23:20:07 sed "s:^:generic/:" /lkp/benchmarks/xfstests/tests/generic-group-09
2026-10-24 23:20:07 ./check -E tests/exclude/ext4 generic/091 generic/092 generic/093 generic/094 generic/095 generic/096 generic/097 generic/098
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 lkp-skl-d01 7.3.0-rc2+ #1 SMP PREEMPT Sat Oct 24 20:47:23 CST 2026
MKFS_OPTIONS  -- -F /dev/sda4
MOUNT_OPTIONS -- -o acl,user_xattr /dev/sda4 /fs/scratch

generic/091        [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//generic/091.out.bad)
    --- tests/generic/091.out	2026-10-19 16:30:12.000000000 +0000
    +++ /lkp/benchmarks/xfstests/results//generic/091.out.bad	2026-10-24 23:20:20.173485972 +0000
    @@ -1,7 +1,25 @@
     QA output created by 091
     fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -W
    ...
    (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/091.out /lkp/benchmarks/xfstests/results//generic/091.out.bad'  to see the entire diff)
generic/092         1s
generic/093         1s
generic/094         14s
generic/095         51s
generic/096         1s
generic/097         2s
generic/098         11s
Ran: generic/091 generic/092 generic/093 generic/094 generic/095 generic/096 generic/097 generic/098
Failures: generic/091
Failed 1 of 8 tests


The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20261026/202610261048.3dc64aea-lkp@intel.com


--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()

[Qu Wenruo]

在 2026/10/26 13:20, kernel test robot 写道:
> 
> Hello,
> 
> kernel test robot noticed "xfstests.generic.091.fail" on:
> 
> commit: 4025185cf953e3f52ab63cf5fec50c1485ee7bb7 ("[PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master patch link: https://lore.kernel.org/all/73bd4d9b39e821453028ca8e567eaad2ebe0fc18.1785880740.git.wqu@suse.com/
> patch subject: [PATCH v4] iomap: follow the alignment requirement for iomap_dio_hole_iter()
> 
> [test failed on linux-next/master 20a33c6b6cbe7e4805dfb6cd68816937443aa148]
> 
> in testcase: xfstests
> version: xfstests-x86_64-22348afe-1_20261019
> with following parameters:
> 
> 	disk: 4HDD
> 	fs: ext4
> 	test: generic-group-09
> 
> 
> config: x86_64-rhel-9.4-func
> compiler: gcc-14
> test machine: 8 threads Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Skylake) with 28G memory
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <yi1.lai@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202610261048.3dc64aea-lkp@intel.com
> 
> 
> 2026-10-24 23:20:06 cd /lkp/benchmarks/xfstests
> 2026-10-24 23:20:07 export TEST_DIR=/fs/sda1
> 2026-10-24 23:20:07 export TEST_DEV=/dev/sda1
> 2026-10-24 23:20:07 export FSTYP=ext4
> 2026-10-24 23:20:07 export SCRATCH_MNT=/fs/scratch
> 2026-10-24 23:20:07 mkdir /fs/scratch -p
> 2026-10-24 23:20:07 export SCRATCH_DEV=/dev/sda4
> 2026-10-24 23:20:07 sed "s:^:generic/:" /lkp/benchmarks/xfstests/tests/generic-group-09
> 2026-10-24 23:20:07 ./check -E tests/exclude/ext4 generic/091 generic/092 generic/093 generic/094 generic/095 generic/096 generic/097 generic/098
> FSTYP         -- ext4
> PLATFORM      -- Linux/x86_64 lkp-skl-d01 7.3.0-rc2+ #1 SMP PREEMPT Sat Oct 24 20:47:23 CST 2026
> MKFS_OPTIONS  -- -F /dev/sda4
> MOUNT_OPTIONS -- -o acl,user_xattr /dev/sda4 /fs/scratch
> 
> generic/091        [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//generic/091.out.bad)
>      --- tests/generic/091.out	2026-10-19 16:30:12.000000000 +0000
>      +++ /lkp/benchmarks/xfstests/results//generic/091.out.bad	2026-10-24 23:20:20.173485972 +0000
>      @@ -1,7 +1,25 @@
>       QA output created by 091
>       fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
>      -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
>      -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
>      -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
>      -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
>      -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -W
>      ...
>      (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/091.out /lkp/benchmarks/xfstests/results//generic/091.out.bad'  to see the entire diff)

Indeed I can reproduce the problem on both ext4 and xfs.

It looks like ext4 and non-COW xfs inodes relies on the unaligned hole 
iterating behavior.

Considering only btrfs and COW xfs inodes requests FSBLOCK_ALIGNED flag, 
for now I'll fix it by only do the revert if it's requested by the dio flag.

Thanks,
Qu

> generic/092         1s
> generic/093         1s
> generic/094         14s
> generic/095         51s
> generic/096         1s
> generic/097         2s
> generic/098         11s
> Ran: generic/091 generic/092 generic/093 generic/094 generic/095 generic/096 generic/097 generic/098
> Failures: generic/091
> Failed 1 of 8 tests
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20261026/202610261048.3dc64aea-lkp@intel.com
> 
> 
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki