Messages in this thread Patch in this message | | | Date | Mon, 19 Sep 2005 19:20:26 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] stop inotify from sending random DELETE_SELF event under load |
| |
On Mon, 19 Sep 2005, John McCutchan wrote: > > To quote you:
Yeah, sometimes I'm more right than other times. That wasn't one of them.
It's actually _almost_ right. The problem being that dentry_iput() is called for non-delete events too.
However, your patch is _worse_. Your patch will cause it not to report the delete at all, because what will happen is that if the delete() is done while somebody else has a pointer to the dentry, then we won't call "dentry_iput()" with a "delete" AT ALL. We will only call it later when the _other_ person (who didn't do a delete) releases the dentry.
See? It's very very wrong to send a flag that depends on the call-chain, because the call-chain is _not_ what determines whether the inode gets deleted or not.
The only way to know whether it gets deleted or not is whan the actual i_nlink goes down to 0, and the inode gets deleted. Ie exactly the generic_delete_inode() case.
But if you keep a reference to the inode, that will never actually happen. Hmm.
Who wants that inode delete event anyway? It's fundamentally harder than removing a name, partly because of the delayed delete, partly because an inode may be reachable multiple ways.
Maybe this patch instead? It's not going to be reliable on networked filesystems, though. Nothing is.
Linus
--- diff --git a/fs/dcache.c b/fs/dcache.c --- a/fs/dcache.c +++ b/fs/dcache.c @@ -102,7 +102,8 @@ static inline void dentry_iput(struct de list_del_init(&dentry->d_alias); spin_unlock(&dentry->d_lock); spin_unlock(&dcache_lock); - fsnotify_inoderemove(inode); + if (!inode->i_nlink) + fsnotify_inoderemove(inode); if (dentry->d_op && dentry->d_op->d_iput) dentry->d_op->d_iput(dentry, inode); else - 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/
| |