From 2bbf2299dfd7624b04981147a11c144eeb2b0b15 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Mon, 23 Jun 2014 10:19:54 +0200 Subject: [PATCH] inotify.7: The watch descriptor reuse bug may be hard to hit in practice Explain the circumstances in detail, indicating that the bug may be very unlikely to occur in practice. Signed-off-by: Michael Kerrisk --- man7/inotify.7 | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/man7/inotify.7 b/man7/inotify.7 index 3480c9236..803c931cf 100644 --- a/man7/inotify.7 +++ b/man7/inotify.7 @@ -755,8 +755,6 @@ instead checked if the most recent event could be coalesced with the .I oldest unread event. -As of Linux 3.15, 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) (or because a watch file is deleted or the filesystem @@ -774,6 +772,18 @@ 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. +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. .SH EXAMPLE The following program demonstrates the usage of the inotify API. It marks the directories passed as a command-line arguments