Re: Question about pseudo filesystems

[Alexander Viro <viro@math.psu.edu>]

On Sun, 8 Sep 2002, Jamie Lokier wrote:

> Alexander Viro wrote:
> > It is neither safe nor needed.  Please, look at the previous posting again -
> > neither variant calls mntput() in ->release().
> > 
> > Now, __fput() _does_ call mntput() - always.  And yes, if that happens to
> > be the final reference - it's OK.
> 
> Thanks, that's really nice.
> 
> I'd assumed `kern_mount' was similar to mounting a normal filesystem,
> but in a non-existent namespace.  Traditionally in unix you can't
> unmount a filesystem when its in use, and mounts don't disappear when
> the last file being used on them disappears.
> 
> But you've rather cutely arranged that these kinds of mount _do_
> disappear when the last file being used on them disappears.  Clever, if
> a bit disturbing.

Normal mount _is_ do_kern_mount() + pinning down the resulting vfsmount +
attaching it to mountpoint.

The second part is what keeps them alive until fs is unmounted.  Moreover,
umount itself is just
	check refcount, return -EBUSY if the thing is busy and MNT_DETACH is
not given.
	detach from mountpoint
	drop the reference

Notice that umount _with_ MNT_DETACH will happily skip that check - and
that will simply detach filesystem from mountpoint with fs shutdown
postponed until it stops being busy.

IOW, filesystem shutdown is _always_ a garbage collection - there's nothing
special about vfsmounts that are not mounted somewhere.  Check for fs
being busy in umount(2) is just a compatibility code - kernel is perfectly
happy with dissolving mountpoints, busy or not.  If stuff mounted is not
busy it will be shut down immediately, if not - when it stops being busy.

It's actually very similar to relation between open(), unlink() and close() -
you can unlink opened files and their contents will be there until the
final close(); then it will be killed.