[lkml]   [2005]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] stop inotify from sending random DELETE_SELF event under load
On Tue, Sep 20, 2005 at 08:34:20AM -0400, John McCutchan wrote:
> Where is the contradiction?
> >fd = open("foo", 0);
> >unlink("foo");
> >sleep for a day
> >fchmod(fd, 0400);
> >sleep for a day
> >close(fd);
> >
> >Which events do we have here? Removal of path happens at unlink();
> >change
> >of attributes - a day later.
> >
> [I'm assuming that fchmod continues to work even if the path has been
> deleted.]

Of course it does.

> With Linus's latest patch:

And IN_DELETE_SELF comes days after the path removal; moreover, it
comes after event that happened after the path removal. To make it
even funnier, have your code do fchmod() only if stat("foo", ...)
returns -ENOENT.

> If we were able to get inoderemove called when the path removal happens,
> At this point, inotify would stop monitoring the inode, and we would
> never see the fchmod.

So if you have
ln a b
start watching b
rm a
chmod 400 b
you'll get no event on that chmod? Both with the current version and
one with your "if we were able" above...

I don't get it. Could you please describe what your code is _supposed_
to do? I'm not even talking about implementation - it's on the level
of "what do we want the watchers to see after the following operations".
Especially since you have fixed ABI - if you have userland clients
relying on the representation of individual events, surely they also
have to assume something about the sequence of events generated when
we do this and that to files and directories?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-20 18:42    [W:0.054 / U:30.936 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site