Independent confirmation on Ubuntu 24.04.4 LTS with the 7.0 HWE kernel, with a
non-gaming reproducer and some notes on the post-oops aftermath.
[System]
Ubuntu 24.04.4 LTS
linux-image-7.0.0-28-generic 7.0.0-28.28~24.04.1 (x86_64)
Lenovo LOQ 15IRH8 (82XV), Intel Core i7-13620H, BIOS LZCN42WW 07/07/2025
/dev/nvme1n1p1, NTFS, auto-mounted by udisks2 as ntfs3:
rw,nosuid,nodev,relatime,uid=1000,gid=1000,acl,iocharset=utf8,prealloc
[Reproducer]
A Next.js 14 production build inside an Nx monorepo, writing its output tree to
the ntfs3 volume. The static-page-generation phase writes thousands of small
files concurrently through the libuv threadpool - i.e. exactly the small /
MFT-resident attribute pattern in the root-cause analysis. No games or Proton
involved, in case a simpler reproducer is useful for bisecting.
Trace matches this bug exactly:
kernel BUG at fs/iomap/buffered-io.c:1061!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 6 UID: 1000 PID: 18163 Comm: node Tainted: P O
7.0.0-28-generic #28~24.04.1-Ubuntu PREEMPT(lazy)
RIP: 0010:iomap_write_end+0x1ea/0x1f0
Call Trace:
<TASK>
iomap_write_iter+0x17a/0x340
iomap_file_buffered_write+0xa5/0x110
ntfs_file_write_iter+0x263/0x300 [ntfs3]
vfs_write+0x29e/0x480
ksys_write+0x71/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x259/0x26e0
do_syscall_64+0xd9/0x5b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[Aftermath - the oops strands the directory tree until reboot]
The task is killed mid-syscall while holding the inode/folio locks, so the
damage outlives the crash. This is why it presents to users as "my file
operation hangs forever and I cannot even kill it":
- All four libuv threadpool threads ended in uninterruptible sleep (D state):
three in filename_unlinkat, one in vfs_unlink. One holds the directory inode
lock and never returns it; the others queue behind it. Their wchan values
were identical across repeated sampling - no forward progress.
- SIGKILL did not clear them. The process became a zombie (Zl) whose threads
remained wedged in D state indefinitely.
- The directory being written (.next/server/app/dashboard) became permanently
un-unlinkable. stat() and a top-level ls still worked, but any attempt to
delete it or traverse into it blocked forever. Only a reboot cleared it.
- kernel.hung_task_timeout_secs is 120, but no hung-task warning was ever
emitted for a confirmed 28-minute stall. Anyone trying to detect this in
the field should not rely on that.
[Regression boundary, verifiable from Ubuntu's shipped binaries]
The iomap conversion can be confirmed from the undefined-symbol tables of the
two installed ntfs3 modules, without booting either kernel:
$ zstdcat /lib/modules/6.17.0-40-generic/kernel/fs/ntfs3/ntfs3.ko.zst >
/tmp/a.ko
$ nm -u /tmp/a.ko | grep -ci iomap
0
$ nm -u /tmp/a.ko | grep -cE 'block_write_begin|block_write_end'
1
$ zstdcat /lib/modules/7.0.0-28-generic/kernel/fs/ntfs3/ntfs3.ko.zst >
/tmp/b.ko
$ nm -u /tmp/b.ko | grep -ci iomap
14 # includes iomap_file_buffered_write
$ nm -u /tmp/b.ko | grep -cE 'block_write_begin|block_write_end'
0
6.17.0-40 has zero iomap references and still uses the buffer_head write path.
7.0.0-28 calls iomap_file_buffered_write, the exact frame in the trace. This is
a quick way to check whether a given Ubuntu kernel is exposed.
[Frequency]
Probabilistic, consistent with the stated root cause. A second worktree of the
same monorepo, on the same ntfs3 volume, built successfully on 7.0.0-28 the
previous day. "It worked yesterday" should not be read as not-affected.
[Workarounds confirmed here]
- Redirecting only the build output to an ext4 path let the identical build
complete. Reads from ntfs3 are fine; the BUG is strictly on the write path.
- Booting 6.17.0-40-generic avoids it entirely. Per the symbol table above,
the faulting code is simply not reachable there.
[Request]
Please cherry-pick 70d3855594cf ("ntfs3: Allocate iomap inline_data using
alloc_page") into the 24.04 HWE 7.0 kernel.
Since 7.0.y is EOL upstream at 7.0.14 without this fix, users on the 24.04 HWE
stack cannot receive it through stable updates. The only options today are
downgrading the kernel or moving volumes to ntfs-3g/FUSE - both a clear
regression from 6.17 behaviour, and neither discoverable without reading a
kernel trace.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162663
Title:
ntfs3: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end on
buffered writes — fixed upstream by 70d3855594cf, needs cherry-pick
(7.0.y is EOL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162663/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
