Re: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem

[Luyao Bai <bailuyao1997@gmail.com>]

On Fri, Jul 24, 2026, Theodore Ts'o wrote:
> And it's not just fsync().  Any caller of ext4_journal_start() will
> end falling into this codepath, which means most ext4 operations
> happening during a freeze could very well fail with an EROFS error.

Thank you both for the review. The Sashiko findings are correct, and I 
now believe this patch is wrong; please consider it withdrawn.

When I reviewed the change, I took the neighbouring checks as
precedent: the sb_rdonly() check just above and the aborted-journal
check below both fail with -EROFS, so I assumed the frozen case should
be handled the same way. What I missed is that those two are permanent
conditions, for which failing is correct, while a freeze is transient:
callers that legitimately reach this point while frozen should block
until thaw, not get an error. The existing WARN_ON() is diagnostic
only and lets the transaction proceed, so replacing it with a hard
-EROFS changes the behavior of every journal start during a freeze.

The race you point out is also real: the check is lockless, so a task
can pass it during SB_FREEZE_FS, block on the journal barrier held by
ext4_freeze(), and then start its transaction right after the freeze
completes. And the underlying report (dirty pages surviving the freeze
when writeback errors are swallowed during sync) looks like it needs
to be handled in the VFS/writeback path, not here.

> Luyao, I'm curious what (if any) testing you performed before
> submitting this patch?

I ran the syzbot C reproducer under QEMU on a clean mainline build to
confirm the WARNING fires, and again with the patch applied to confirm
it no longer does, plus a build of fs/ext4/ and checkpatch. I did not
exercise fsync-during-freeze or the freeze/thaw transition (e.g. the
fstests freeze tests), which is why the problems above escaped me.

> And I'm curious if some AI / LLM was used in
> the preparation of this patch?

Yes. The patch was prepared with the assistance of LLM-based tooling I
am experimenting with for kernel bug fixing; I reviewed the change,
built it and ran the reproducer myself, and I take full responsibility
for it under the DCO. I should have included an Assisted-by: tag per
Documentation/process/coding-assistants.rst, and I apologize for
omitting it. Future submissions from me will carry the tag.

Thanks again for the careful review, and sorry for the noise.

Luyao