Re: [patch] stop inotify from sending random DELETE_SELF event under load

[Al Viro]

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:
> 
> IN_ATTRIB
> IN_DELETE_SELF
> IN_IGNORE

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,
>
> IN_DELETE_SELF
> IN_IGNORE
> 
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/