From: Miklos Szeredi <[email protected]>
This series addresses the problem of showing mount options in
/proc/mounts.
Several filesystems which use mount options, have not implemented a
.show_options superblock operation. Several others have implemented
this callback, but have not kept it fully up to date with the parsed
options.
Q: Why do we need correct option showing in /proc/mounts?
A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
this are:
- unprivileged mounters won't be able to update /etc/mtab
- /etc/mtab doesn't work with private mount namespaces
- /etc/mtab can become out-of-sync with reality
Q: Can't this be done, so that filesystems need not bother with
implementing a .show_mounts callback, and keeping it up to date?
A: Only in some cases. Certain filesystems allow modification of a
subset of options in their remount_fs method. It is not possible
to take this into account without knowing exactly how the
filesystem handles options.
For the simple case (no remount or remount resets all options) the
patchset introduces two helpers:
generic_show_options()
save_mount_options()
These can also be used to emulate the old /etc/mtab behavior, until
proper support is added. Even if this is not 100% correct, it's still
better than showing no options at all.
The following patches fix up most in-tree filesystems, they have been
compile tested only. I would like to ask maintainers (CC-d on
respective patches) to please review, test and ACK these changes.
The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
Reiser4. For CIFS, NFS and XFS I wasn't able to understand how some
of the options are used. The last two are not yet in mainline, so I
leave fixing those to their respective maintainers out of pure
laziness.
Table displaying status of all in-kernel filesystems:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
legend:
none - fs has options, but doesn't define ->show_options()
some - fs defines ->show_options(), but some only options are shown
most - fs defines ->show_options(), and shows most of them
good - fs shows all options
noopt - fs does not have options
patch - a patch will be posted
9p good
adfs patch
affs patch
afs patch
autofs patch
autofs4 patch
befs patch
bfs noopt
cifs some
coda noopt
configfs noopt
cramfs noopt
debugfs noopt
devpts patch
ecryptfs good
efs noopt
ext2 patch
ext3 good
ext4 patch
fat patch
freevxfs noopt
fuse patch
fusectl noopt
gfs2 good
gfs2meta noopt
hfs good
hfsplus good
hostfs patch
hpfs patch
hppfs noopt
hugetlbfs patch
isofs patch
jffs2 noopt
jfs patch
minix noopt
msdos ->fat
ncpfs patch
nfs patch,most
nfsd noopt
ntfs good
ocfs2 good
ocfs2/dlmfs noopt
openpromfs noopt
proc noopt
qnx4 noopt
ramfs noopt
reiserfs patch
romfs noopt
smbfs good
sysfs noopt
sysv noopt
udf patch
ufs good
vfat ->fat
xfs most
mm/shmem.c patch
drivers/oprofile/oprofilefs.c noopt
drivers/infiniband/hw/ipath/ipath_fs.c noopt
drivers/misc/ibmasm/ibmasmfs.c noopt
drivers/usb/core (usbfs) patch
drivers/usb/gadget (gadgetfs) noopt
drivers/isdn/capi/capifs.c patch
kernel/cpuset.c noopt
fs/binfmt_misc.c noopt
net/sunrpc/rpc_pipe.c noopt
arch/powerpc/platforms/cell/spufs patch
arch/s390/hypfs good
ipc/mqueue.c noopt
security (securityfs) noopt
security/selinux/selinuxfs.c noopt
kernel/cgroup.c good
security/smack/smackfs.c noopt
in -mm:
reiser4 some
unionfs none
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This patch:
Document the rules for handling mount options in the .show_options
super operation.
Signed-off-by: Miklos Szeredi <[email protected]>
---
Index: linux/Documentation/filesystems/vfs.txt
===================================================================
--- linux.orig/Documentation/filesystems/vfs.txt 2008-01-24 11:42:48.000000000 +0100
+++ linux/Documentation/filesystems/vfs.txt 2008-01-24 17:12:25.000000000 +0100
@@ -151,7 +151,7 @@ The get_sb() method has the following ar
const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
- string
+ string (see "Mount Options" section)
struct vfsmount *mnt: a vfs-internal representation of a mount point
@@ -182,7 +182,7 @@ A fill_super() method implementation has
must initialize this properly.
void *data: arbitrary mount options, usually comes as an ASCII
- string
+ string (see "Mount Options" section)
int silent: whether or not to be silent on error
@@ -291,7 +291,8 @@ or bottom half).
umount_begin: called when the VFS is unmounting a filesystem.
- show_options: called by the VFS to show mount options for /proc/<pid>/mounts.
+ show_options: called by the VFS to show mount options for
+ /proc/<pid>/mounts. (see "Mount Options" section)
quota_read: called by the VFS to read from filesystem quota file.
@@ -969,6 +970,45 @@ manipulate dentries:
For further information on dentry locking, please refer to the document
Documentation/filesystems/dentry-locking.txt.
+Mount Options
+=============
+
+Parsing options
+---------------
+
+On mount and remount the filesystem is passed a string containing a
+comma separated list of mount options. The options can have either of
+these forms:
+
+ option
+ option=value
+
+The <linux/parser.h> header defines an API that helps parse these
+options. There are plenty of examples on how to use it in existing
+filesystems.
+
+Showing options
+---------------
+
+If a filesystem accepts mount options, it must define show_options()
+to show all the currently active options. The rules are:
+
+ - options MUST be shown which are not default or their values differ
+ from the default
+
+ - options MAY be shown which are enabled by default or have their
+ default value
+
+Options used only internally between a mount helper and the kernel
+(such as file descriptors), or which only have an effect during the
+mounting (such as ones controlling the creation of a journal) are exempt
+from the above rules.
+
+A simple method of saving options at mount/remount time and showing
+them is provided with the save_mount_options() and
+generic_show_options() helper functions. Please note, that using
+these may have drawbacks. For more info see header comments for these
+functions in fs/namespace.c.
Resources
=========
--
In message <[email protected]>, Miklos Szeredi writes:
> From: Miklos Szeredi <[email protected]>
>
> This series addresses the problem of showing mount options in
> /proc/mounts.
>
> Several filesystems which use mount options, have not implemented a
> .show_options superblock operation. Several others have implemented
> this callback, but have not kept it fully up to date with the parsed
> options.
[...]
> The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
> Reiser4. For CIFS, NFS and XFS I wasn't able to understand how some
> of the options are used. The last two are not yet in mainline, so I
> leave fixing those to their respective maintainers out of pure
> laziness.
>
> Table displaying status of all in-kernel filesystems:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> legend:
>
> none - fs has options, but doesn't define ->show_options()
> some - fs defines ->show_options(), but some only options are shown
> most - fs defines ->show_options(), and shows most of them
> good - fs shows all options
> noopt - fs does not have options
> patch - a patch will be posted
[...]
> in -mm:
>
> reiser4 some
> unionfs none
Hi Miklos,
Where did you check for the existence of a ->show_options method for
unionfs? Unionfs does implement ->show_options and supports all of the
mount/remount options. See:
<http://git.kernel.org/?p=linux/kernel/git/ezk/unionfs.git;a=blob;f=fs/unionfs/super.c;h=986c980261a5b171147d66ac05bf08423e2fd6b6;hb=HEAD#l963>
The unionfs ->remount code supports branch-management options which can
add/del/change a branch, but we don't show those directly in ->show_options;
it makes more sense to show the final (and thus most current) branch
configuration.
Could you update your records please?
BTW, I should be able to use your save_mount_options().
Cheers,
Erez.
> In message <[email protected]>, Miklos Szeredi writes:
> > From: Miklos Szeredi <[email protected]>
> >
> > This series addresses the problem of showing mount options in
> > /proc/mounts.
[...]
> > The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
> > Reiser4. For CIFS, NFS and XFS I wasn't able to understand how some
> > of the options are used. The last two are not yet in mainline, so I
> > leave fixing those to their respective maintainers out of pure
> > laziness.
XFS has already been updated. The fix is in the XFs git tree that
Andrew picks up for -mm releases and will be merged in the 2.6.25-rc1
window. Commit is here:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=8c33fb6ca99aa17373bd3d5a507ac0eaefb7abb4
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
> Where did you check for the existence of a ->show_options method for
> unionfs? Unionfs does implement ->show_options and supports all of the
> mount/remount options. See:
>
> <http://git.kernel.org/?p=linux/kernel/git/ezk/unionfs.git;a=blob;f=fs/unionfs/super.c;h=986c980261a5b171147d66ac05bf08423e2fd6b6;hb=HEAD#l963>
>
> The unionfs ->remount code supports branch-management options which can
> add/del/change a branch, but we don't show those directly in ->show_options;
> it makes more sense to show the final (and thus most current) branch
> configuration.
>
> Could you update your records please?
Sure. Sorry about that, I did actually look at unionfs, and it was
just an administration error and bad memory (in my head).
> BTW, I should be able to use your save_mount_options().
It is probably better not to use save_mount_options(). Especially,
since unionfs implemets a remount, that changes the tree only
partially AFAICS.
Miklos
Hi,
On Thursday 24. January 2008, Miklos Szeredi wrote:
> Q: Why do we need correct option showing in /proc/mounts?
> A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
> this are:
> - unprivileged mounters won't be able to update /etc/mtab
> - /etc/mtab doesn't work with private mount namespaces
> - /etc/mtab can become out-of-sync with reality
I asked this before and I don't remember getting an answer:
How does this deal with certain special cases:
- chroot: how will mount/df only show the for chroot relevant mounts?
- loop: how is the connection between file and loop device maintained?
I don't quite see how you want to achieve a _full_ replacement.
Could also please explain why you want to go via user mounts. Other OS use a
daemon for that, which e.g. can maintain access controls. How do you want to
manage this?
bye, Roman
> > Q: Why do we need correct option showing in /proc/mounts?
> > A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
> > this are:
> > - unprivileged mounters won't be able to update /etc/mtab
> > - /etc/mtab doesn't work with private mount namespaces
> > - /etc/mtab can become out-of-sync with reality
>
> I asked this before and I don't remember getting an answer:
> How does this deal with certain special cases:
> - chroot: how will mount/df only show the for chroot relevant mounts?
That is a very good question. Andreas Gruenbacher had some patches
for fixing behavior of /proc/mounts under a chroot, but people are
paranoid about userspace ABI changes (unwarranted in this case, IMO).
http://lkml.org/lkml/2007/4/20/147
Anyway, if we are going to have a new 'mountinfo' file, this could be
easily fixed as well.
> - loop: how is the connection between file and loop device maintained?
We also discussed this with Karel, maybe it didn't make it onto lkml.
The proposed solution was to store the "loop" flag separately in a
file under /var. It could just be an empty file for each such loop
device:
/var/lib/mount/loops/loop0
This file is created by mount(8) if the '-oloop' option is given. And
umount(8) automatically tears down the loop device if it finds this
file.
> I don't quite see how you want to achieve a _full_ replacement.
I think a full replacement is perfectly feasible, just needs some more
work on the userspace side.
> Could also please explain why you want to go via user mounts. Other OS use a
> daemon for that, which e.g. can maintain access controls. How do you want to
> manage this?
The unprivileged mounts patches do contain a simple form of access
control. I don't think anything more is needed, but of course, having
unprivileged mounts in the kernel does not prevent the use of a more
sophisticated access control daemon in userspace, if that becomes
necessary.
Miklos
On Wed, Jan 30, 2008 at 10:09:03AM +0100, Miklos Szeredi wrote:
> > - loop: how is the connection between file and loop device maintained?
>
> We also discussed this with Karel, maybe it didn't make it onto lkml.
>
> The proposed solution was to store the "loop" flag separately in a
> file under /var. It could just be an empty file for each such loop
> device:
>
> /var/lib/mount/loops/loop0
>
> This file is created by mount(8) if the '-oloop' option is given. And
> umount(8) automatically tears down the loop device if it finds this
> file.
It seems we needn't this solution. There is loop auto-destruction
patch in -mm.
Kernel part:
http://marc.info/?l=linux-kernel&m=119361296818388&w=2
mount(8) part:
http://marc.info/?l=util-linux-ng&m=119362955431694&w=2
So, with this patch mount(8) needn't to maintain info about loops and
umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
is enough.
Karel
--
Karel Zak <[email protected]>
> > > - loop: how is the connection between file and loop device maintained?
> >
> > We also discussed this with Karel, maybe it didn't make it onto lkml.
> >
> > The proposed solution was to store the "loop" flag separately in a
> > file under /var. It could just be an empty file for each such loop
> > device:
> >
> > /var/lib/mount/loops/loop0
> >
> > This file is created by mount(8) if the '-oloop' option is given. And
> > umount(8) automatically tears down the loop device if it finds this
> > file.
>
> It seems we needn't this solution. There is loop auto-destruction
> patch in -mm.
>
> Kernel part:
> http://marc.info/?l=linux-kernel&m=119361296818388&w=2
>
> mount(8) part:
> http://marc.info/?l=util-linux-ng&m=119362955431694&w=2
>
> So, with this patch mount(8) needn't to maintain info about loops and
> umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
> is enough.
Excellent! This is a very good example how moving a functionality
into the kernel can greatly simplify it.
Thanks,
Miklos
Hi,
On Wed, 30 Jan 2008, Miklos Szeredi wrote:
> > How does this deal with certain special cases:
> > - chroot: how will mount/df only show the for chroot relevant mounts?
>
> That is a very good question. Andreas Gruenbacher had some patches
> for fixing behavior of /proc/mounts under a chroot, but people are
> paranoid about userspace ABI changes (unwarranted in this case, IMO).
>
> http://lkml.org/lkml/2007/4/20/147
>
> Anyway, if we are going to have a new 'mountinfo' file, this could be
> easily fixed as well.
>
> > - loop: how is the connection between file and loop device maintained?
>
> We also discussed this with Karel, maybe it didn't make it onto lkml.
>
> The proposed solution was to store the "loop" flag separately in a
> file under /var. It could just be an empty file for each such loop
> device:
>
> /var/lib/mount/loops/loop0
>
> This file is created by mount(8) if the '-oloop' option is given. And
> umount(8) automatically tears down the loop device if it finds this
> file.
My question was maybe a little short. I don't doubt that we can shove a
lot into the kernel, the question is rather how much of this will be
unnecessary information, which the kernel doesn't really need itself.
> > Could also please explain why you want to go via user mounts. Other OS use a
> > daemon for that, which e.g. can maintain access controls. How do you want to
> > manage this?
>
> The unprivileged mounts patches do contain a simple form of access
> control. I don't think anything more is needed, but of course, having
> unprivileged mounts in the kernel does not prevent the use of a more
> sophisticated access control daemon in userspace, if that becomes
> necessary.
A "I don't think anything more is needed" lets go off all sorts of warning
lights. Most things start out simple, so IMO it's very worth it to check
where it might go to to know the limits beforehand. The main question here
is why should a kernel based solution be preferable over a daemon based
solution?
If we look for example look at OS X, it has no need for user mounts but
has a daemon instead, which also provides an interesting notification
system for new devices, mounts or unmount requests. All this could also be
done in the kernel, but where would be the advantage in doing so? The
kernel implementation would be either rather limited or only bloat the
kernel. What is the feature that would make user mounts more than just a
cool kernel hack?
bye, Roman
> > > Could also please explain why you want to go via user
> > > mounts. Other OS use a daemon for that, which e.g. can maintain
> > > access controls. How do you want to manage this?
> >
> > The unprivileged mounts patches do contain a simple form of access
> > control. I don't think anything more is needed, but of course, having
> > unprivileged mounts in the kernel does not prevent the use of a more
> > sophisticated access control daemon in userspace, if that becomes
> > necessary.
>
> A "I don't think anything more is needed" lets go off all sorts of warning
> lights. Most things start out simple, so IMO it's very worth it to check
> where it might go to to know the limits beforehand. The main question here
> is why should a kernel based solution be preferable over a daemon based
> solution?
A daemon based solution would work for the "normal" case, where we
have a single mount namespace and a single /etc/mtab file, and we hope
it doesn't get too much out of sync with what is actually in the
kernel (on remount the mount options do get out of sync, but hey, we
seem to be able to live with that).
However, once you start using multiple namespaces, the daemon based
solution quickly becomes unusable, because you would need a separate
daemon for each namespace, and it would have to somehow keep track of
mount propagations in userspace (which is basically impossible), etc,
etc...
Does that answer your question?
Thanks,
Miklos