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

[nf <nf2 scheinwelt at>]

On Sat, 2004-06-05 at 15:39, John McCutchan wrote:
> On Sat, 2004-06-05 at 05:15, nf2 scheinwelt at wrote:
> > 
> > Just to put this right: Nonotify does NOT require open fd's, it does NOT pin
> > down dentries and it does NOT block cdrom ejection.
> > 
> > Nonotify just uses a modified stat-call to read the new 'dcontents_mtime' field.
> > Nothing else. Stat-calls don't open fd's and don't block.
> 
> Yes it does. When you call stat() there is a bunch of activity on the
> filesystem that will stop cdrom ejection during the stat call. Assuming
> that nonotify is stat()ing every X ms, there is a race between the
> stat() call and the unmount. So it could happen, but it would be rare.
> 

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?

Norbert