public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: John McCutchan <ttb@tentacle.dhs.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: Tue, 20 Sep 2005 04:31:48 +0100	[thread overview]
Message-ID: <20050920033148.GA7992@ftp.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0509191821220.2553@g5.osdl.org>

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.  

IOW, let the notification of link removal check ->i_nlink and add
"that was the last one" event if it had hit zero.  Or, better yet,
pass i_mode and i_nlink in the event itself and let the recepient
do obvious checks.

  parent reply	other threads:[~2005-09-20  3:31 UTC|newest]

Thread overview: 41+ 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  9:15                                               ` Joel Becker
2005-09-21  9:17                                                 ` Christoph Hellwig
2005-09-21 14:45                                                   ` Joel Becker
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 [this message]
2005-09-20  3:51     ` John McCutchan
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=20050920033148.GA7992@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@novell.com \
    --cc=torvalds@osdl.org \
    --cc=ttb@tentacle.dhs.org \
    --cc=viro@ZenIV.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox