Re: [syzbot] [kernfs?] [ext4?] INFO: task hung in sb_start_write (2)

[Matthias Goergens <matthias.goergens@gmail.com>]

The C reproducer neither demonstrates a kernel bug nor matches the
crashes already collected in this bucket:
https://syzkaller.appspot.com/bug?extid=b3fba2e269970207b61d

It lowers hung_task_timeout_secs to 15, issues ioctl(FIFREEZE) on the
root filesystem, then forks a child that opens an O_TMPFILE there.
The child blocks in sb_start_write, as any write must while the
filesystem is frozen. The reproducer sleeps for 60 seconds before
thawing, so the hung-task report fires only because it shortened the
timeout below its own sleep. The default 120s timeout would not
trigger. Any CAP_SYS_ADMIN process can produce this report on any
kernel: this is fsfreeze working as designed. Whether a task waiting
for thaw should be exempt from hung-task reporting is a separate,
older question.

The pre-existing crashes differ. In the 2025-08-01, 2025-08-23 and
2026-08-02 instances, the blocked task waits on the sb_writers of a
filesystem the fuzzer mounted from an image: lockdep classes
sb_writers#31, sb_writers#13 and sb_writers#20 respectively. In the
same reports, the root filesystem's writers class appears separately
with a low number (sb_writers#5 held by udevd and others). The
reproducer instead reports sb_writers#4, the root filesystem that it
froze itself.

The captured console logs for the three organic crashes contain no
FIFREEZE call. One contains a single stray FITHAW, so a freeze before
the captured log window cannot be excluded, but that must be
established before treating this reproducer as the explanation. If a
fuzzer-issued FIFREEZE on a mounted image caused the hangs, the fix
is for syzkaller to sanitise FIFREEZE, and the bug is still not in the
kernel. Otherwise, something wedged those superblocks' writer gates
with no fsfreeze in sight, which is a real bug that closing this
report on the strength of the reproducer would bury. The mix of image
filesystems mounted by those runs also explains why the subsystem
guesses span kernfs, ext4, jfs, xfs and bcachefs.

I therefore suggest treating this reproducer as matching the
signature, not the cause. A previous generic-signature hung-task
bucket, "task hung in do_rmdir"
(https://syzkaller.appspot.com/bug?extid=e68dbebd9617a9250e8d),
contained a real ext4 livelock. It was fixed by commit 54b6bd40898d
("ext4: stop retrying saturated xattr cache entries") in the ext4
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?id=54b6bd40898d

Such buckets can hide real bugs behind an uninformative victim stack;
the per-instance reports contain the distinguishing evidence.