Re: 2.6.17-rc3 - fs/namespace.c issue

[Herbert Poetzl <herbert@13thfloor.at>]

On Tue, May 02, 2006 at 02:56:23AM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 02 May 2006 01:56:37 +0200, Herbert Poetzl said:
> > > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f6422f17d3a480f21917a3895e2a46b968f56a08
> 
> > first, what do we expect from --bind mounts regarding
> > vfs (mount) level flags like noatime, noexec, nodev?
> > 
> >  - should they be propagated from the original mfs/mount?
> 
> I tripped over this apparent regression when I hit a problem with some
> code that expected this behavior. Given the documented behavior of the
> mount syscall (see below), apparently propagating all flags intact
> and clearing all flags are the only 2 options that don't break the
> documented API.
> 
> >  - should they only restrict the original set?
> >  - should they allow to modify the existing flags?
> 
> Well, absent a '-o newflags' to modify it, propagating the originals
> probably follows the Principle of Least Surprise.   And whether mountflags
> are permissible is an API change issue...
> 
> > IMHO, it makes perfect sense to mount something noatime
> > and change that rule later for a subtree like this:
> > 
> >  mkdir /foo
> >  mount -t tmpfs -o rw,noatime none /foo
> >  mkdir /foo/bar
> >  mount --bind -o atime /foo/bar /foo/bar
> 
> Here, there's a -o parameter being passed.

yes, but this information unfortunately cannot be passed 
to the kernel, assuming that we 'preserve' the original
mount flags, as there simply is no 'atime' flag, just an
MS_NOATIME flag, which in this case is not set :)

> > second, has the kernel to decide what flags userspace
> > can request and/or change, depending on the original?
> 
> Can of worms, too complicated for 3AM. :)
> 
> > and finally, how to handle --rbind mounts at a level
> > deeper than the top?
> 
> More worms. ;)

it's full of worms, maybe we should add a new option or
even a new mount type for this?

maybe we should allow remount on bind mounts, and keep
the original (copy all) behaviour intact for --bind and
--rbind mounts? (that would look most natural to me)

suggestions welcome!

best,
Herbert

> Note that any provision for changing the mountflags *IS* a break of
> the documented API.  'man 2 mount' says specifically:
> 
>        MS_BIND
>               (Linux 2.4 onwards) Perform a bind mount, making a
>               file or a directory subtree visible at another point
>               within a file system. Bind mounts may cross file system
>               boundaries and span chroot(2) jails. The filesystemtype,
>               mountflags, and data arguments are ignored.
> 
> I admit not knowing that whether POSIX or other standards specify that
> mountflags be ignored.