Re: [PATCH] iomap: only follow dio alignment requirement if specified

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2026/10/27 07:29, Qu Wenruo 写道:
> 
> 
> 在 2026/10/27 06:19, Pankaj Raghav (Samsung) 写道:
>> On Mon, Oct 26, 2026 at 05:18:13PM +1030, Qu Wenruo wrote:
>>>
>>> [CAUSE]
>>> The failed command of fsx is COPY_RANGE:
>>>
>>>   copy range: 0x6800 to 0xa200 at 0x3f200
>>>   do_copy_range:: Resource temporarily unavailable
>>>   LOG DUMP (8 total operations):
>>>   1(  1 mod 256): SKIPPED (no operation)
>>>   2(  2 mod 256): SKIPPED (no operation)
>>>   3(  3 mod 256): WRITE    0x14400 thru 0x211ff    (0xce00 bytes) HOLE
>>>   4(  4 mod 256): FALLOC   0x72bf4 thru 0x76221    (0x362d bytes) 
>>> EXTENDING
>>>   5(  5 mod 256): SKIPPED (no operation)
>>>   6(  6 mod 256): INSERT 0x11000 thru 0x13fff    (0x3000 bytes)
>>>   7(  7 mod 256): TRUNCATE DOWN    from 0x79221 to 0xa800
>>>   8(  8 mod 256): COPY 0x6800 thru 0xa1ff    (0x3a00 bytes) to 
>>> 0x3f200 thru 0x42bff
>>>   Log of operations saved to "/mnt/test/junk.fsxops"; replay with -- 
>>> replay-ops
>>>   Correct content saved for comparison
>>>   (maybe hexdump "/mnt/test/junk" vs "/mnt/test/junk.fsxgood")
>>>
>>> Both ext4 and xfs only require direct IO to be aligned to the logical
>>> block size of the device, not the fs block size. So the 0x3a00 bytes
>>> read at 0x6800 is allowed, and should succeed.
>>>
>>> But that range is a hole, and that commit makes iomap_dio_hole_iter()
>>> round the zeroed length down to the fs block size unconditionally.
>>> The first iteration zeroes 0x3a00 bytes but only advances 0x3000 bytes,
>>> then the next iteration zeroes the remaining 0xa00 bytes, which is
>>> rounded down to 0, so -EFAULT is returned.
>>>
>>> As ext4 and xfs do not pass IOMAP_DIO_PARTIAL, the whole read fails
>>> with -EFAULT, which is then converted to -EAGAIN by copy_splice_read().
>>> Every retry of fsx hits the same -EAGAIN, failing the run.
>>>
>>> That commit breaks all direct reads which range is not fs block aligned
>>> for ext4 and xfs.
>>>
>>> [FIX]
>>> Do not revert the range unless the dio has IOMAP_DIO_FSBLOCK_ALIGNED 
>>> flag.
>>>
>>> iomap_dio_hole_iter() is only called for reads, and for now only btrfs
>>> reads can reach this path with the flag set. Btrfs has the proper
>>> fallback when dio returns -EFAULT.
>>>
>>> Fixes: 4025185cf953 ("iomap: follow the alignment requirement for 
>>> iomap_dio_hole_iter()")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>> ---
>>>   fs/iomap/direct-io.c | 26 ++++++++++++++++----------
>>>   1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>
>> Ignore my previous question (I had a old version of xfstests).
>> I was able to reproduce the error on XFS, ext4 and this patch fixes it.
>>
>> One small nit: should we update the IOMAP_DIO_FSBLOCK_ALIGNED flag
>> documentation to reflect this?
>>
>> At the moment the document says "Ensure each bio is aligned to fs block
>> size". Should we expand it to say "Ensure each bio and any progress
>> reported for hole/unwritten extents is aligned to fs block size"?
> 
> I'll change it to something like "Ensure every operation, including bio 
> and folio zeroing, is aligned to fs block size".
> 
> Will be included in the next update.
> 
> Thanks,
> Qu
> 
>>
>> But the changes look good to me, so:
>> Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>
>>

BTW, the address in your reviewed-by tag doesn't match with your mail 
address, thus b4 is rejecting the tag.