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

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

(sorry for the broken message sent yesterday)

On Tue, 25 Oct 2005 15:00:41 +0100 Al Viro wrote:

> On Tue, Oct 25, 2005 at 03:20:10PM +0200, Schupp Roderich (extern) BenQ MD PD SWP 2 CM MCH wrote:
> > the 2.6.13 and 2.6.14-* kernels seem susceptible to a race condition
> > between the sending of a "mount" uevent and the actual mount becoming
> > visible thru /proc/mounts, at least when the kernel is configured
> > with voluntary preemption. 

The "umount" uevent has the same problem - the event is emitted at the
start of umount process, but the umount can really complete much later
(e.g., if there was a lot of cached writes).  This is really bad,
because the "umount" uevent cannot be used to tell the user when it is
safe to remove the device.

> > The following scenario: 
> > - system is using the HAL daemon, configured to monitor kernel uvents
> > - someone (usually some kind of volume manager in response to
> >   a device hotplug, but could also a manual mount) mounts a filesystem
> > - "mount" uevent is emitted
> 
> ... said event happens to be a piece of junk with ill-defined semantics.

Hmm, and what should be the proper semantics for such an event?

Currently the "mount" uevent signals that the device is busy (and the
"umount" uevent then should signal that the device is no longer in use,
but that is currently broken).

> > - HAL daemon reads the event, then opens and reads /proc/mounts
> 
> real useful, since
> 	a) we have no idea if mount() is being done in the same namespace
> 	b) we have no idea if mount() actually succeeds
> 	c) even if we manage to find a mountpoint, we have no idea if it
> gets e.g. mount --move just as we'd finished reading from /prov/mounts
> 	d) if the goal is to see which devices are held by mounted fs,
> you'll miss such things as e.g. external journals.
> 
> >   (in order to determine the corresponding mount point, since the uevent
> 
> *the* corresponding mountpoint?  Which one?  There might be any number
> of those...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]