Messages in this thread | | | Date | Sat, 7 Sep 2002 22:43:46 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Question about pseudo filesystems |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |