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...
