From: John McCutchan <ttb@tentacle.dhs.org>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Robert Love <rml@novell.com>, Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [patch] stop inotify from sending random DELETE_SELF event under load
Date: Mon, 19 Sep 2005 23:51:44 -0400 [thread overview]
Message-ID: <1127188304.17794.11.camel@vertex> (raw)
In-Reply-To: <20050920033148.GA7992@ftp.linux.org.uk>
On Tue, 2005-09-20 at 04:31 +0100, Al Viro wrote:
> On Mon, Sep 19, 2005 at 06:37:43PM -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.
> >
> > 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.
> >
> > Al, do you have any comments? Anything stupid I missed?
>
> One fundamentally stupid thing is exposing to userland events that
> are none of its fscking business. Link removal - sure. Last link
> removal - perhaps, but that's not obvious; in any case it should be
> tied to notification of link removal. But inode getting freed or
> last dentry going away is none of the userland concern.
I just thought I should clarify exactly when we want to send the
DELETE_SELF event to user space:
A path which points to inode X has been deleted.
--
John McCutchan <ttb@tentacle.dhs.org>
next prev parent reply other threads:[~2005-09-20 3:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-20 0:48 [patch] stop inotify from sending random DELETE_SELF event under load John McCutchan
2005-09-20 1:37 ` Linus Torvalds
2005-09-20 2:00 ` John McCutchan
2005-09-20 2:20 ` Linus Torvalds
2005-09-20 3:46 ` John McCutchan
2005-09-20 4:03 ` Linus Torvalds
2005-09-20 4:24 ` Al Viro
2005-09-20 4:30 ` Linus Torvalds
2005-09-20 4:36 ` John McCutchan
2005-09-20 4:46 ` Al Viro
2005-09-20 4:53 ` John McCutchan
2005-09-20 4:58 ` Al Viro
2005-09-20 5:06 ` John McCutchan
2005-09-20 5:17 ` Al Viro
2005-09-20 12:34 ` John McCutchan
2005-09-20 16:38 ` Al Viro
2005-09-20 17:44 ` Ray Lee
2005-09-20 18:12 ` Linus Torvalds
2005-09-20 18:22 ` Al Viro
2005-09-20 19:37 ` Linus Torvalds
2005-09-20 22:53 ` John McCutchan
2005-09-21 0:33 ` Linus Torvalds
2005-09-21 0:52 ` John McCutchan
2005-09-21 1:01 ` Al Viro
2005-09-21 1:41 ` John McCutchan
2005-09-21 2:36 ` Al Viro
2005-09-21 8:35 ` Christoph Hellwig
2005-09-21 4:15 ` [Ocfs2-devel] " Joel Becker
2005-09-21 9:15 ` Joel Becker
2005-09-21 9:17 ` Christoph Hellwig
2005-09-21 9:45 ` [Ocfs2-devel] " Joel Becker
2005-09-21 14:45 ` Joel Becker
2005-09-21 13:08 ` [Ocfs2-devel] " Mark Fasheh
2005-09-21 18:08 ` Mark Fasheh
2005-09-20 18:26 ` John McCutchan
2005-09-20 19:39 ` Linus Torvalds
2005-09-20 4:56 ` Linus Torvalds
2005-09-20 4:52 ` Linus Torvalds
2005-09-20 4:27 ` John McCutchan
2005-09-20 3:33 ` Al Viro
2005-09-20 3:50 ` John McCutchan
2005-09-20 3:31 ` Al Viro
2005-09-20 3:51 ` John McCutchan [this message]
2005-09-20 8:33 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1127188304.17794.11.camel@vertex \
--to=ttb@tentacle.dhs.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
--cc=torvalds@osdl.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.