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

[John McCutchan]

On 20-Sep-05, at 1:17 AM, Al Viro wrote:

> On Tue, Sep 20, 2005 at 01:06:23AM -0400, John McCutchan wrote:
>
> > On Tue, 2005-09-20 at 05:58 +0100, Al Viro wrote:
> >
> > > On Tue, Sep 20, 2005 at 12:53:12AM -0400, John McCutchan wrote:
> > >
> > > > DELETE_SELF WD=X
> > > >
> > > > The path you requested a watch on (inotify_add_watch(path,mask)  
> > > > returned
> > > > X) has been deleted.
> > >
> > > Then why the devil do we have IN_DELETE and IN_DELETE_SELF generated
> > > in different places?  The only difference is in who receives the
> > > event - you send IN_DELETE to watchers on parent and IN_DELETE_SELF
> > > on watchers on victim.  Event itself is the same, judging by your
> > > description...
> >
> > No, because in the case of IN_DELETE, the path represented by the WD
> > hasn't been deleted, it is "PATH(WD)/event->name" that has been.
>
> That's OK - same thing described for different recepients, thus two
> events with different contents and type being sent.
>
>
> > Also,
> > IN_DELETE_SELF marks the death of the WD, no further events will  
> > be sent
> > with the same WD [Except for the IN_IGNORE].
>
> Uh-oh...  Now, _that_ is rather interesting - you are giving self- 
> contradictory
> descriptions of the semantics.

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.]

With Linus's latest patch:

IN_ATTRIB
IN_DELETE_SELF
IN_IGNORE

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.

John McCutchan
ttb@xxxxxxxxxxxxxxxx



-
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/