Re: [PATCH v4 7/9] iomap: use loff_t for file positions and offsets in writeback code

[Joanne Koong <joannelkoong@gmail.com>]

On Tue, Nov 18, 2025 at 7:40 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Nov 11, 2025 at 11:36:56AM -0800, Joanne Koong wrote:
> > Use loff_t instead of u64 for file positions and offsets to be
> > consistent with kernel VFS conventions. Both are 64-bit types. loff_t is
> > signed for historical reasons but this has no practical effect.
>
> generic/303       run fstests generic/303 at 2025-11-19 03:27:51
> XFS: Assertion failed: imap.br_startblock != DELAYSTARTBLOCK, file: fs/xfs/xfs_reflink.c, line: 1569
> ------------[ cut here ]------------
> kernel BUG at fs/xfs/xfs_message.c:102!
> Oops: invalid opcode: 0000 [#1] SMP NOPTI
> CPU: 8 UID: 0 PID: 2422 Comm: cp Not tainted 6.18.0-rc1-ktest-00035-gb94488503277 #169 NONE
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:assfail+0x3c/0x46
> Code: c2 e0 cc 40 82 48 89 f1 48 89 fe 48 c7 c7 e3 60 45 82 48 89 e5 e8 e4 fd ff ff 8a 05 16 98 55 01 3c 01 76 02 0f 0b a8 01 74 02 <0f> 0b 0f 0b 5d c3 cc cc cc cc 48 8d 45 10 4c 8d 6c 24 10 48 89 e2
> RSP: 0018:ffff888111433cf8 EFLAGS: 00010202
> RAX: 00000000ffffff01 RBX: 0007ffffffffffff RCX: 000000007fffffff
> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffffffff824560e3
> RBP: ffff888111433cf8 R08: 0000000000000000 R09: 000000000000000a
> R10: 000000000000000a R11: 0fffffffffffffff R12: 0000000000000001
> R13: 00000000ffffff8b R14: ffff888105280000 R15: 0007ffffffffffff
> FS:  00007fc4cd191580(0000) GS:ffff8881f6ccb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005612bbfade30 CR3: 000000011146c000 CR4: 0000000000750eb0
> PKRU: 55555554
> Call Trace:
>  <TASK>
>  xfs_reflink_remap_blocks+0x259/0x450
>  xfs_file_remap_range+0xe9/0x3d0
>  vfs_clone_file_range+0xde/0x460
>  ioctl_file_clone+0x50/0xc0
>  __x64_sys_ioctl+0x619/0x9d0
>  ? do_sys_openat2+0x99/0xd0
>  x64_sys_call+0xed0/0x1da0
>  do_syscall_64+0x6a/0x2e0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> RIP: 0033:0x7fc4cd34d37b
> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> RSP: 002b:00007ffeb4734050 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fc4cd34d37b
> RDX: 0000000000000003 RSI: 0000000040049409 RDI: 0000000000000004
> RBP: 00007ffeb4734490 R08: 00007ffeb4734660 R09: 0000000000000002
> R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000008000 R15: 0000000000000002
>  </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:assfail+0x3c/0x46
> Code: c2 e0 cc 40 82 48 89 f1 48 89 fe 48 c7 c7 e3 60 45 82 48 89 e5 e8 e4 fd ff ff 8a 05 16 98 55 01 3c 01 76 02 0f 0b a8 01 74 02 <0f> 0b 0f 0b 5d c3 cc cc cc cc 48 8d 45 10 4c 8d 6c 24 10 48 89 e2
> RSP: 0018:ffff888111433cf8 EFLAGS: 00010202
> RAX: 00000000ffffff01 RBX: 0007ffffffffffff RCX: 000000007fffffff
> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffffffff824560e3
> RBP: ffff888111433cf8 R08: 0000000000000000 R09: 000000000000000a
> R10: 000000000000000a R11: 0fffffffffffffff R12: 0000000000000001
> R13: 00000000ffffff8b R14: ffff888105280000 R15: 0007ffffffffffff
> FS:  00007fc4cd191580(0000) GS:ffff8881f6ccb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005612bbfade30 CR3: 000000011146c000 CR4: 0000000000750eb0
> PKRU: 55555554
> Kernel panic - not syncing: Fatal exception
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>

First off, it's becoming clear to me that I didn't test this patchset
adequately enough. I had run xfstests on fuse but didn't run it on
XFS. My apologies for that, I should have done that and caught these
bugs myself, and will certainly do so next time.

For this test failure, it's because the change from u64 to loff_t is
overflowing loff_t on xfs. The failure is coming from this line change
in particular:

-static unsigned iomap_find_dirty_range(struct folio *folio, u64 *range_start,
- u64 range_end)
+static unsigned iomap_find_dirty_range(struct folio *folio, loff_t
*range_start,
+ loff_t range_end)

which is called when writing back the folio (in iomap_writeback_folio()).

I added some printks and it's overflowing because we are trying to
write back a 4096-byte folio starting at position 9223372036854771712
(2^63 - 4096) in the file which results in an overflowed end_pos of
9223372036854775808 (2^63) when calculating folio_pos + folio_size.

I'm assuming XFS uses these large folio positions as a sentinel/marker
and that it's not actually a folio at position 9223372036854771712,
but either way, this patch doesn't seem viable with how XFS currently
works and I think it needs to get dropped.

I'm going to run the rest of the xfstests suite on XFS for this
patchset series to verify there are no other issues.

Thanks,
Joanne