From: Miklos Szeredi <mszeredi@suse.cz>

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 ...
[ message continues ]

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

[ message continues ]

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=8c33fb6ca99aa17373b...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
--

[ message continues ]

Sure.  Sorry about that, I did actually look at unionfs, and it was

It is probably better not to use save_mount_options().  Especially,
since unionfs implemets a remount, that changes the tree only
partially AFAICS.

Miklos
--

[ message continues ]

Hi,


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

[ message continues ]

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

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

I think a full replacement is perfectly feasible, just needs some more

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

[ message continues ]

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  <kzak@redhat.com>
--

[ message continues ]

Excellent!  This is a very good example how moving a functionality
into the kernel can greatly simplify it.

Thanks,
Miklos
--

[ message continues ]

Hi,


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 

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

[ message continues ]

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

[ message continues ]