On Mon, Jun 23, 2014 at 11:45 AM, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > Hello Michael, > > the further descripton is fine for me. Please, integrate it into the inotify(7) page. Thanks, Heinrich. Done. Cheers, Michael > Heinrich Schuchardt > > Am 23.06.14 um 10:21 schrieb Michael Kerrisk (man-pages) > >> On 06/22/2014 04:45 PM, Heinrich Schuchardt wrote: >> >> > The revised patch below uses the wording suggested by Michael Kerrisk. >> >> > >> >> > *** >> >> > >> >> > Watch descriptor IDs are returned by inotify_add_watch. >> >> > When calling inotify_rm_watch an IN_IGNORE is placed on the inotify queue >> >> > pointing to the ID of the removed watch. >> >> > >> >> > inotify_add_watch should not return a watch descriptor ID for which events are >> >> > still on the queue but should return an unused ID. >> >> > >> >> > Unfortunately the existing Kernel code does not provide such a guarantee. >> >> > >> >> > Actually in rare cases watch descriptor IDs are returned by inotify_add_watch >> >> > for which events are still on the inotify queue. >> >> > >> >> > cf. https://bugzilla.kernel.org/show_bug.cgi?id=77111 >> >> > >> >> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx> >> >> > --- >> >> > man7/inotify.7 | 18 ++++++++++++++++++ >> >> > 1 file changed, 18 insertions(+) >> >> > >> >> > diff --git a/man7/inotify.7 b/man7/inotify.7 >> >> > index 1fc83f8..d64523f 100644 >> >> > --- a/man7/inotify.7 >> >> > +++ b/man7/inotify.7 >> >> > @@ -754,6 +754,24 @@ if the older had not yet been read) >> >> > instead checked if the most recent event could be coalesced with the >> >> > .I oldest >> >> > unread event. >> >> > + >> >> > +As of Linux 3.15.1, the following bug exists: >> >> > +.\" FIXME https://bugzilla.kernel.org/show_bug.cgi?id=77111 >> >> > +When a watch descriptor is removed by calling >> >> > +.BR inotify_rm_watch (2), >> >> > +any pending unread events for that watch descriptor remain available to read. >> >> > +As watch descriptors are subsequently allocated with >> >> > +.BR inotify_add_watch (2), >> >> > +the kernel cycles through the range of possible watch descriptors (0 to >> >> > +.BR INT_MAX ) >> >> > +incrementally. >> >> > +When allocating a free watch descriptor, no check is made to see whether that >> >> > +watch descriptor number has any pending unread events in the inotify queue. >> >> > +Thus, it can happen that a watch descriptor is reallocated even >> >> > +when pending unread events exist for a previous incarnation of >> >> > +that watch descriptor number, with the result that the application >> >> > +might then read those events and interpret them as belonging to >> >> > +the file associated with the newly recycled watch descriptor. >> >> > .SH EXAMPLE >> >> > The following program demonstrates the usage of the inotify API. >> >> > It marks the directories passed as a command-line arguments >> >> >> >> Thanks, Heinrich. Applied with some minor tweaks, and pushed to >> >> kernel.org Git. >> >> >> >> I also added this piece: >> >> >> >> [[ >> >> In practice, the likelihood of hitting this bug may be extremely low, >> >> since it requires that an application cycle through >> >> .B INT_MAX >> >> watch descriptors, >> >> release a watch descriptor while leaving unread events for that >> >> watch descriptor in the queue in the queue, >> >> and then recycle that watch descriptor. >> >> For this reason, and because there have been no reports >> >> of the bug occurring in real-world applications, >> >> as of Linux 3.15, >> >> .\" FIXME https://bugzilla.kernel.org/show_bug.cgi?id=77111 >> >> no kernel changes have yet been made to eliminate this possible bug. >> >> ]] >> >> >> >> Okay? >> >> >> >> Cheers, >> >> >> >> Michael >> >> >> >> >> >> -- >> >> Michael Kerrisk >> >> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ >> >> Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
