Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes

[nf <nf2 scheinwelt at>]

On Sat, 2004-06-05 at 17:14, John McCutchan wrote:
> On Sat, 2004-06-05 at 10:10, nf wrote:
> > Interesting point! But is it true? I actually tried to explore this
> > yesterday by brute-force attacking a mounted dir with stat-calls, but
> > unmounting never was blocked. It seems that reading the inode-attributes
> > is "almost" atomic. 
> > 
> > I don't know enough about the spin_lock() function. I thought it
> > synchronizes access to a certain resource, rather than throwing an
> > error. Can you show me the place in the kernel, where the umount
> > blocking via "stat" would happen?
> > 
> 
> Of course its true, the kernel would never access the filesystem with
> out making sure that it wouldn't disappear mid-access. Check out
> vfs_stat() in fs/stat.c user_path_walk pins dentries as it walks the
> path you pass it, then it pins down the inode while it gets its
> attributes in to the stat structure. Like I said it is a race that is
> probably going to be hard to trigger, but it can happen. This will make
> it much harder/impossible to provide deterministic behavior to the user.

You are right. Stat() calls invoke dget() and dput() on dentries - thus
affecting usage counts. 

Although there seems to be lots of synchronization involved (spin_locks)
also - hence there might be a chance that umount will pause and wait for
the stat() call to finish. I really don't know. I always thought that
stat() does not block umount - and that the umount problem is only
caused by open fds.

There would be two ways to work around this problem:

* Pragmatic but not pretty: Repeat umount if it fails.

* Better: Find a way to synchronize nonotify_stat and umount (don't let
them happen at the same time).

Norbert