Re: [RFC] MNT_WRITE_HOLD mess

[Al Viro <viro@zeniv.linux.org.uk>]

On Sat, Jul 05, 2025 at 07:53:59PM +0100, Al Viro wrote:
> On Sat, Jul 05, 2025 at 01:01:14AM +0100, Al Viro wrote:
> 
> > FWIW, several observations around that thing:
> > 	* mnt_get_write_access(), vfs_create_mount() and clone_mnt()
> > definitely do not need to touch the seqcount component of mount_lock.
> > read_seqlock_excl() is enough there.
> > 	* AFAICS, the same goes for sb_prepare_remount_readonly(),
> > do_remount() and do_reconfigure_mnt() - no point bumping the seqcount
> > side of mount_lock there; only spinlock is needed.
> > 	* failure exit in mount_setattr_prepare() needs only clearing the
> > bit; smp_wmb() is pointless there (especially done for each mount involved).
> 
> The following appears to work; writing docs now...

	More fun questions in the area: is there any reason we have mnt_want_write()
doing
int mnt_want_write(struct vfsmount *m)
{
        int ret;

        sb_start_write(m->mnt_sb);
        ret = mnt_get_write_access(m);
        if (ret)
                sb_end_write(m->mnt_sb);
        return ret;
}
rather than
int mnt_want_write(struct vfsmount *m)
{
        int ret = mnt_get_write_access(m);
	if (!ret)
		sb_start_write(m->mnt_sb);
        return ret;
}

	Note that mnt_want_write_file() on e.g. a regular file opened
for write will have sb_start_write() done with mnt_get_write_access()
already in place since open(2).  So the nesting shouldn't be an issue
here...  The same order (mount then superblock) is used for overlayfs
copyup, for that matter.

	So if it's a matter of waiting for thaw with mount write
count already incremented, simple echo foo > pathname would already
demonstrate the same, no matter of which order mnt_want_write() uses.
What am I missing there?

	IIRC, that was Jan's stuff... <checks git log> yep - eb04c28288bb
"fs: Add freezing handling to mnt_want_write() / mnt_drop_write()" is
where it came from...