Dear Maintainer,

* What led up to the situation?

I was running a backup script using rsync to copy files from a BTRFS
filesystem (mounted via dm-crypt/LUKS) to an NTFS filesystem inside a
VeraCrypt-encrypted container (also backed by dm-crypt). The source files
included a mix of large and small files.

* What exactly did you do (or not do) that was effective (or ineffective)?

I ran the rsync backup multiple times across several days, on both kernel
7.0.12+deb14.1-amd64 and 7.0.13+deb14-amd64. The crash occurred
reproducibly during sustained write operations to the NTFS3 filesystem,
always while rsync was actively writing files. I confirmed via process
state monitoring (ps aux) that after the crash, the rsync process entered
an uninterruptible sleep (D state) and could not be terminated even with
SIGKILL.

I initially suspected USB disconnects or GPU driver issues (I also have
known amdgpu driver instabilities on this RX 9070 XT system), but kernel
log timestamps showed the "kernel BUG at fs/iomap/buffered-io.c:1061!"
message occurring within 1-2 seconds of the rsync write error
("Broken pipe"), ruling out those other causes as the trigger for this
specific crash.

* What was the outcome of this action?

The kernel emitted:
  kernel BUG at fs/iomap/buffered-io.c:1061!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  RIP: 0010:iomap_write_end+...

The rsync process(es) became permanently stuck in D state, requiring a
full system reboot to recover. The underlying BTRFS and EXT4 filesystems
performed automatic recovery/remount on the subsequent boot, suggesting
the filesystems themselves were left in an inconsistent state by the
crash.

This appears to match publicly reported issues with the same crash
signature on other systems (CachyOS kernel 7.0.x), specifically
identified as occurring during buffered writes to NTFS3 filesystems
via ntfs_file_write_iter().