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