Re: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem
"Theodore Tso" <[email protected]> Fri, 24 Jul 2026 09:31:19 -0400
| Newsgroups | org.kernel.vger.linux-ext4,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]?part=1