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

John McCutchan
2005-09-20T12:34:34Z

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@tentacle.dhs.org