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

[Valdis.Kletnieks@vt.edu]

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.

> 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. ;)

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.

Attachment: pgp4ZvChU5O3p.pgp
Description: PGP signature