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

[John McCutchan <ttb tentacle dhs org>]

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.

John