> > > Interesting... How do you deal with mount propagation and things like
> > > mount --move?
> >
> > Moving (or doing other mount operations on) an ancestor shouldn't be a
> > problem. Moving this mount itself is not allowed, and neither is
> > doing bind or pivot_root. Maybe bind could be allowed...
>
> Eh... Arbitrary limitations are fun, aren't they?
But these mounts _are_ special. There is really no point in moving or
pivoting them.
> > When doing recursive bind on ancestor, these mounts are skipped.
>
> What about clone copying your namespace?
In that case they are cloned, but only those survive which have refs
in the new namespace.
> What about MNT_SLAVE stuff being set up prior to that lookup?
These mounts are not propagated. Or at least I hope so. Propagation
stuff is a bit too complicated for my poor little brain.
> More interesting question: should independent lookups of that sucker
> on different paths end up with the same superblock (and vfsmount for
> each) or should we get fully independent mount on each? The latter
> would be interesting wrt cache coherency...
I think they should be the same superblock, same dentry. What would
be the advantage of doing otherwise?
> > > As for unlink... How do you deal with having that thing
> > > mounted, mounting something _under_ it (so that vfsmount would be kept
> > > busy) and then unlinking that sucker?
> >
> > Yeah, that's a good point. Current patch doesn't deal with that.
> > Simplest solution could be to disallow submounting these. Don't think
> > it makes much sense anyway.
>
> Arbitrary limitations... (and that's where revalidate horrors come in, BTW).
> BTW^2: what if fs mounted that way will happen to have such node itself?
I think doing this recursively should be allowed. "Releasing last ref
cleans up the mess" should work in that case.
> I'm not saying that it's unfeasible or won't lead to interesting things,
> but it really needs semantics done right...
Agreed :)
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
