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

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Nov 19, 2025 at 10:10:40AM -0800, Joanne Koong wrote:
> 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.

xfs supports 9223372036854775807-byte files, so 0x7FFFFFFFFFFFF000
is a valid location for a folio.

--D

> 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