Re: [RFC/PATCH] inotify -- a dnotify replacement

[viro]

On Tue, May 11, 2004 at 08:20:01AM -0400, John McCutchan wrote:
 
> Inotify will support watching a hierarchy. The reason it was not
> implemented yet is because the one app that I really care about is
> nautilus and the maintainer of it says he doesn't care. 

How are you going to implement that?

> The big feature that inotify is trying to provide is not having to keep
> a file open (So that unmounting is not affected). I asked for some
> guidance from people more familiar with the kernel so that I can
> implement this feature, it requires changes made to the inode cache, and
> how unmounting is done.

Bzzert.  First of all, on quite a few filesystems inumbers are stable
only when object is pinned down.  What's more, if it's not pinned down
you've got nothing even remotely resembling a reliable way to tell if
two events had happened to the same object - inumbers can be reused.

Besides, your "doesn't pin down" is racy as hell - not to mention the
way you manage the lists, pretty much every function is an exploitable
hole.  Hell, just take a look at your "find inode" stuff - you grab
superblock, find an inode by inumber (great idea, that - especially
since on a bunch of filesystems it will get you BUG() or equivalent)
then drop refernce to superblock (at which point it can be destroyed by
umount()) _and_ do iput() (which will do lovely, lovely things if that
umount did happen).  Moreover, you return a pointer to inode, even
though there's nothing to hold it alive anymore.  And dereference that
pointer later on, not caring if it had been freed/reused/whatever.

Overall: hopeless crap.  And that's a direct result of your main feature -
it's really broken by design.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/