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

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

On Tue, Oct 25, 2005 at 03:20:10PM +0200, Schupp Roderich (extern) BenQ MD PD SWP 2 CM MCH wrote:
> Hi,
> 
> 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 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.

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