Messages in this thread | | | Date | Wed, 12 May 1999 19:26:08 +0200 | From | Matthew Wilcox <> | Subject | Re: [VFS] move active filesystem |
| |
On Wed, May 12, 1999 at 01:12:17PM -0400, Alexander Viro wrote: > On Wed, 12 May 1999, Matthew Wilcox wrote: > > On Wed, May 12, 1999 at 11:55:14AM -0400, Alexander Viro wrote: > > > It looks sane, but... I don't see where it prevents remounting of /usr to > > > /usr/local/foo. Could you comment on this? > > > > You are correct, it does not prevent that. My reasoning is that root > > has a large number of ways to screw up the system already and detaching > > a filesystem from the namespace by a trick like this is pretty minor > > in comparison. After all, the filesystem may be reattached later. > > A check could be added for the simplest case (preventing mounting a > > filesystem on itself, but consider: [...] > > Would a check that the current mount point is not a prefix of the new > > mount point be sufficient to catch all possible loops?
> Look at it that way: currently filesystems form a tree. Parent can be > found by ->s_root->d_covers->d_inode->i_sb. To prevent loops you need to > preserve tree structure. So yes, checking that we are not moving the fs > under itself is OK here - mounts are serialized wrt each other.
provided we have suitable locking, yes I agree.
> > Another question... is this necessarily a bad thing? Yes, it can get you > > into situations that you can't get into now, but you can always return > > to a sensible state. I'm having trouble thinking of a use for this that > > chroot doesn't give you, to be fair. > > suppose /foo is remounted on /foo/bar/baz. And your PWD was /foo/bar. > Bummer. Try to call d_path() after that. Or simply run find. > > Another thing to consider: behaviour of NFS-exported filesystems. That has > nothing to loops. Look at the export table handling in knfsd. AFAICS it > may bite you if you are moving the stuff around that way. > > And another one: interaction with lookups. I have a nasty gut feeling that > in current form it has really unpleasant races waiting to happen as soon > as we'll allow to move mountpoints *not* dropping the whole tree under > them.
Okay, you convinced me. Should the check go in the kernel or in mount(8)?
-- Matthew Wilcox <willy@bofh.ai> "Windows and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture." - N Stephenson
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |