Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

[Bodo Eggert <7eggert@gmx.de>]

On Sat, 30 Apr 2005, Steve French wrote:

> There is one remaining issue with mount and umount - the user space 
> utilities.   By the way who maintains
> them these days?   Although the mount utilities allow filesystem 
> specific mount and umount helpers
> to be placed in /sbin and automatically executed for the matching 
> filesystem type, there are a few functions
> that belong in common code - in a system library which today have to be 
> implemented in every helper
> function and of course are implemented in different ways in different 
> distros and
> different tools with possibility of corruption of the /etc/mtab.

For user mounts, there should be no practical way of maintaining mtab,
especially if the users are using private namespaces (as suggested in 
another thread) or if they are supposed to be able to unmount using
a non-suid generic umount.

>   It 
> may be that the file /etc/mtab
> does not matter and that it needs to go away and everyone needs to look 
> at /proc/mounts instead, but
> in the meantime /etc/mtab can easily get out of sync with the actual 
> list of mounts, although that
> usuallly does not prevent unmount from working it may be confusing.

The drawback of /proc/mounts is not showing the -oloop information.
Either it's easy to implement showing that extra information, or you'll
need a ~/.etc/mtab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/