Re: [PATCH v2 24/34] btrfs: don't set SB_RDONLY after filesystem errors

[sashiko-bot@kernel.org]

> __btrfs_handle_fs_error() sets SB_RDONLY through btrfs_set_sb_rdonly()
> without holding s_umount. It runs from any context and every transaction
> abort ends up there. That races with everyone else changing sb->s_flags.
> And if it happens while the filesystem is frozen thaw_super() sees a
> read-only superblock and leaves the s_writers rwsems locked. Today only
> btrfs_zone_finish_endio_workfn() can get there after ->freeze_fs() but
> that's luck.
> 
> btrfs doesn't need SB_RDONLY for any of this. fs_error already stops new
> transactions and BTRFS_FS_STATE_RO is what btrfs checks since the
> previous patch. So only set that like ext4 and f2fs do and call
> sb_set_emergency_ro() so the VFS refuses modifications and reports the
> superblock as read-only. That's not done for the shutdown ioctl, rescue
> mounts or a superblock that already carries the error flag.
> 
> A remount to read-only now actually happens after an error, so
> btrfs_remount_ro() skips the commit and the unused block group pass that
> can't succeed anymore. Going read-write fails with EROFS instead of
> EINVAL. ->sync_fs returns 0 and btrfs_freeze() skips its commit in that
> state so freezing keeps working, and the thaw skips check_dev_super()
> because the superblocks on disk may not match after an error.
> 
> A second read-write mount of the filesystem succeeds now. A non-forced
> remount to read-only fails with EBUSY while files that were opened for
> writing before the error are still open.
> 
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-work-fs-sb_rdonly-v2-0-2f44f64f0b66@kernel.org?part=24