Re: [PATCH] super: remember whether freeze holds writer rwsems

From: Karl Mehltretter

Date: Thu Sep 03 2026 - 15:38:42 EST


On Thu, Sep 03, 2026 at 02:44:19PM +0100, Oleg Nesterov wrote:
> > Tested with a test-only KUnit case in x86_64 QEMU on linux-next
> > 32b6ef9a5d0e (next-20260902). It freezes a writable ramfs, sets SB_RDONLY,
> > thaws it, and calls sb_start_write_trylock(). The call fails without this
> > patch and succeeds with it.
>
> But I am curious, how exactly did you test this?
>
> ramfs_ops doesn't have ->freeze_fs or ->freeze_super, so
> ioctl_fsfreeze() should fail?
>
> And how it is possible to remount with -ro, reconfigure_super() should
> see sb->s_writers.frozen != SB_UNFROZEN ?
>
Hi Oleg,

Thank you for the review!

The original test called freeze_super() directly, changed SB_RDONLY,
and called thaw_super().
Ramfs only supplied an initialized superblock.
It did not use FIFREEZE or a normal remount.

I have now tested real filesystem error paths in x86_64 QEMU:

Filesystem Baseline this VFS patch
---------- ------------------------------- -------------------------------
ext2 write hangs after thaw, write succeeds unmount is clean
unmount gives three
rcu_sync_dtor() warnings
NILFS2 unmount gives three unmount is clean
rcu_sync_dtor() warnings
JFS write hangs in VFS rwsem is released then the
percpu_rwsem_wait() write hangs in JFS txBegin()

The ext2 and NILFS2 tests use real FIFREEZE and FITHAW and corrupted disk
metadata.

The JFS result also shows the scope of the patch. It balances the VFS rwsems,
but JFS skips txResume() after seeing SB_RDONLY. Needs JFS fix.

Karl