Re: 2.6.17-rc3 - fs/namespace.c issue
From: Valdis . Kletnieks
Date: Tue May 02 2006 - 02:56:35 EST
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:
(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
I admit not knowing that whether POSIX or other standards specify that
mountflags be ignored.
Description: PGP signature