Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- From: John McCutchan <ttb tentacle dhs org>
- To: nf2 scheinwelt at
- Cc: Nautilus mailing <nautilus-list gnome org>, "Manuel Amador \(Rudd-O\)" <amadorm usm edu ec>, Alexander Larsson <alexl redhat com>
- Subject: Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- Date: Sat, 05 Jun 2004 11:14:27 -0400
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.
] [Thread Prev