Re: [patch] stop inotify from sending random DELETE_SELF event under load

[John McCutchan <ttb@tentacle.dhs.org>]

On Mon, 2005-09-19 at 18:37 -0700, Linus Torvalds wrote:
> 
> On Mon, 19 Sep 2005, John McCutchan wrote:
> > 
> > Below is a patch that fixes the random DELETE_SELF events when the
> > system is under load. The problem is that the DELETE_SELF event is sent
> > from dentry_iput, which is called in two code paths,
> > 
> > 1) When a dentry is being deleted
> > 2) When the dcache is being pruned.
> 
> No no.
> 
> The problem is that you put the "fsnotify_inoderemove(inode);" in the 
> wrong place, and I and Al never noticed.
> 

To quote you:

Instead of the broken fsnotify_unlink/fsnotify_rmdir functions, you can 
split this into two logically _different_ functions:

 - fsnotify_nameremove(dentry) - called when the dentry goes away
 - fsnotify_inoderemove(dentry) - called when the inode goes away

...

The fsnotify_inoderemove() is called from dentry_iput(), and that's the 
one that specifies that an actual inode no longer exists.


;)

> iput() doesn't have anything to do with delete at all, and adding a flag 
> to it would be wrong. The inode may stay around _after_ the unlink() for 
> as long as it has users (or much longer, if you have hardlinks ;). 
> 
> You should probably move the "fsnotify_inoderemove(inode);" call into
> generic_delete_inode() instead, just after "security_inode_delete()".  No
> new flags, just a new place.
> 
> (Oh, I think you need to add it to "hugetlbfs_delete_inode()" too).
> 
> There's still a potential problem there: some network filesystems seem to
> use "generic_delete_inode()" as their "drop_inode" thing. Which may mean 
> that you get spurious delete messages when the reference is dropped. I 
> don't see how to avoid that, though - we fundamentally don't _know_ when 
> the inode actually gets deleted.
> 


I don't think moving it to generic_delete_inode is the right place. 
Anyways, generic_delete_inode is called when the final reference on the
inode is released, but inotify keeps a reference on the inode, so I
don't think it would work.

fsnotify_inoderemove should be called after the dentry for the file is
removed, not when the inode actually goes away. The behaviour inotify
users expect is:

$ watch /tmp/foo (wd = 0)
$ rm /tmp/foo
event sent: DELETE_SELF (wd = 0)

Inotify doesn't care if the inode for /tmp/foo is sticking around for
whatever reason. As far as inotify is concerned, the file is deleted.

-- 
John McCutchan <ttb@tentacle.dhs.org>