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

[Karl Mehltretter <kmehltretter@gmail.com>]

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