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 <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-06-23 10:19:54 +02:00
parent e530e367e2
commit 2bbf2299df
1 changed files with 12 additions and 2 deletions

View File

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