Messages in this thread | | | Subject | Re: [patch] stop inotify from sending random DELETE_SELF event under load | From | John McCutchan <> | Date | Mon, 19 Sep 2005 22:00:41 -0400 |
| |
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> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |