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.
