Re: Race between "mount" uevent and /proc/mounts?

[Al Viro <viro@ftp.linux.org.uk>]

On Thu, Nov 03, 2005 at 01:52:35PM +0300, Sergey Vlasov wrote:
> > Ugh...  So umount -l gives one hell of a spew for no good reason.
> 
> umount -l will change contents of /proc/mounts, so waking up poll() on
> that file seems to be right in this case (even if the filesystem is still
> mounted internally, it is no longer accessible).

Yes, but that's a single change.
 
> > Bad idea - copy_tree() will spew *and* we get bogus events on CLONE_NEWNS
> > (i.e. current->namespace is not even the namespace being modified).
> 
> IMHO it's not spew, but real changes in the mount tree.

Again, mount --rbind is a single change.  And fsckloads of attach_mnt().
IOW, you are doing that on too low level.  Right ones:

	* graft_tree()
	* do_move_mount()
	* sys_pivot_root()
	* expire_mount() (BTW, again wrong namespace touched in your variant)
	* lazy one in umount_tree() (single update of event in do_umount(),
then touch ->mnt_namespace for each vfsmount - with shared-subtree it may
affect more than one namespace)
	* couple of extra places introduced by shared-subtree patchset


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel