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

["Theodore Tso" <tytso@mit.edu>]

On Fri, Jul 24, 2026 at 10:11:01AM -0500, Christian Brauner wrote:
> I can't say whether this is the right fix but it feels hacky and racy
> unless this code holds s_umount - which it may well do.

Oh, it's worse than that.  From the Sashiko review[1]:

> [Severity: High]
> Does returning -EROFS here cause fsync() to spuriously fail? If userspace
> calls fsync() on a file with dirty pages while the filesystem is in
> SB_FREEZE_COMPLETE, since fsync() bypasses VFS freeze locks, it seems it
> would hit this new path and fail with -EROFS instead of safely blocking
> until the freeze is lifted.

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.

> Also, is there a TOCTOU race with SB_FREEZE_FS here? If a background
> writeback thread evaluates this lockless check while VFS is in the
> SB_FREEZE_FS phase, it will evaluate to false and proceed to
> jbd2__journal_start() where it blocks on the journal barrier. When
> ext4_freeze() finishes, it drops the barrier and VFS sets
> SB_FREEZE_COMPLETE. The blocked thread then wakes up and starts a
> transaction on the now-frozen filesystem.

Luyao, I'm curious what (if any) testing you performed before
submitting this patch?  And I'm curious if some AI / LLM was used in
the preparation of this patch?

Thanks,

						- Ted

[1] https://sashiko.dev/#/patchset/20260723205036.661832-1-bailuyao1997@gmail.com?part=1