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

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

On Wed, Oct 26, 2005 at 04:34:17PM +0200, Kay Sievers wrote:
> > Semantics for events depends on which objects you are interested in.
> > Existing ones do not match _any_ of the real objects and I have no
> > idea what exactly had been intended for them.  I've asked gregkh, but
> > he didn't remember that either.  Apparently they are used by different
> > people as (bad) approximations to different things.  Which doesn't work
> > well.  And until somebody cares to describe what exactly are they trying
> > to watch the situation obviously won't improve.
> 
> They are actually events for claim/release of a block device. As uevents
> are bound to kobjects we needed to send these events from an existing device
> which is the blockdev itself.
> 
> Sure, the event itself, has nothing to do with a filesystem. The names are
> like this for historical reasons and "CLAIM/RELEASE" may be less confusing.
> The events are used as a trigger to rescan /proc/mounts instead of polling
> it constantly.

But that makes no sense.  /proc/*/mounts changes when mount tree changes.
Which is obviously not an event happening to block devices.  Moreover,
changes of mount tree may involve no changes in the set of active filesystems
or be separated in time from such changes by arbitrary intervals.

Looks like seriously wrong assumptions in userland code working with these
events...  _IF_ you want to keep track of /proc/*/mounts changes, the obvious
solution would be to implement ->poll() for them.  However, if you are
really interested in block devices, keep in mind that
	* getting them claimed happens before your event is generated
	* eventually the filesystem claiming them becomes active (or doesn't,
if mount fails)
	* eventually an active fs may (or may not) become visible in mount
tree.
	* not every umount leads to deactivation
	* deactivation can happen long after the fs is no longer present in
mount tree
	* fs may become visible in mount tree again without being deactivated
and activated again - (mount /dev/foo /mnt; exec </mnt/bar; umount -l /mnt;
sleep 100; mount /dev/foo /tmp/barf) in case of block filesystem will do just
that; fs gets activated, mounted, unmounted and mounted again 100 seconds
later.
	* deactivated fs gives up its claim on device(s).  Incidentally,
your UMOUNT event is triggered before either thing happens; any amount of
IO on the device(s) can happen after it.

Oh, and there are things other than filesystems that can (and do) claim
block devices.

So what's really going on?  If you want to know when device gets busy, you
need events in fs/block_dev.c and no expectation regarding /proc/mounts.
If you want to know when mount tree changes, you need events on attach_mnt/
detach_mnt (and I would seriously suggest ->poll() rather than wanking with
events).  If you want something more complex, you might or might not be
SOL, depending on what you are trying to achieve.
-
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/