From: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
To: Jeff Smith <jsmith.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
John McCutchan
<john-jueV0HHMeujJJrXXpGQQMAC/G2K4zDHf@public.gmane.org>,
Robert Love <rlove-L7G0xEPcOZbYtjvyW6yDsg@public.gmane.org>,
Eric Paris <eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org>,
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Subject: Re: inotify_rm_watch() user-space safety requirements?
Date: Tue, 27 May 2014 21:32:11 +0200 [thread overview]
Message-ID: <5384E83B.1030209@gmx.de> (raw)
In-Reply-To: <CAAih0NjG4gC-7fkD5vOvF0CQks+DhqVZLeycsju-8RMVP6dbBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 27.05.2014 19:25, Jeff Smith wrote:
> inotify's behavior concerning events from removed watches (they do
> happen) and watch descriptor reuse (beyond my knowledge) is currently
> undocumented.
>
> Although it mimics a standard multiplexing interface in most regards,
> writing a robust user-space handler is comparatively more complex due
> to the atypical delivery of "stale" wd events preceding an IN_IGNORE
> event and a lack of guarantees about how quickly a wd can be reused
> via inotify_add_watch(). Not being familiar with inotify/fsnotify
> internals, it's not trivially obvious to me how the fsnotify_group
> management is being done. Up to the present, I've maintained queues of
> "dead" wd wrappers (or at least a counter) to filter stale events, but
> I am clueless whether or not this is overkill.
>
> If removed descriptors are reserved until the IN_IGNORE event is
> drained from the read queue, could that be formally guaranteed? If
> it's not, is it functionality that could ever reasonably be expected
> to be added, short of some other form of new (optional?)
> queue-filter-on-rm functionality? It's my experience that the
> asynchronous handling of watch removals is a cost that seldom serves
> much user benefit.
>
> Regards,
> Jeff
Hello Jeff,
I tried to dive a bit into the code. This is what I understand:
Function inotify_ignored_and_remove_idr is called after the mark has
been removed. This function puts an IN_IGNORED event onto the inotify
queue and removes the watch descriptor from the list of used watch
descriptors using function idr_remove.
With a test program I could receive the IN_IGNORED event. This behavior
is currently not documented in the manpages (inotify.7 and
inotify_rm_watch.2).
When inotify_add_watch is called it uses function idr_alloc_cyclic to
assign a watch descriptor ID. This function starts looking for an unused
id starting with the id after the last assigned watch descriptor.
This implies that in most cases inotify_add_watch will return a watch
descriptor different to the one released by a prior call to
inotify_rm_watch. But there is no guarantee.
I consider this a bug.
I CCed the maintainers of the inotify interface hoping that they can
provide a better solution.
Until such a solution is provided I suggest you use the following
workaround. After calling inotify_rm_watch read from the inotify file
descriptor until you reach the matching IN_IGNORED event.
Only thereafter you can safely call inotify_add_watch again.
Best regards
Heinrich Schuchardt
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next parent reply other threads:[~2014-05-27 19:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAih0NjG4gC-7fkD5vOvF0CQks+DhqVZLeycsju-8RMVP6dbBw@mail.gmail.com>
[not found] ` <CAAih0NjG4gC-7fkD5vOvF0CQks+DhqVZLeycsju-8RMVP6dbBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-27 19:32 ` Heinrich Schuchardt [this message]
[not found] ` <5384E83B.1030209-Mmb7MZpHnFY@public.gmane.org>
2014-05-27 20:04 ` inotify_rm_watch() user-space safety requirements? Jeff Smith
2014-05-31 5:26 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5384E83B.1030209@gmx.de \
--to=xypron.glpk-mmb7mzphnfy@public.gmane.org \
--cc=eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org \
--cc=jack-AlSwsSmVLrQ@public.gmane.org \
--cc=john-jueV0HHMeujJJrXXpGQQMAC/G2K4zDHf@public.gmane.org \
--cc=jsmith.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=rlove-L7G0xEPcOZbYtjvyW6yDsg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).