All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Michael Kerrisk-manpages
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Robert Love <rlove-L7G0xEPcOZbYtjvyW6yDsg@public.gmane.org>,
	"linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	gamin-list-rDKQcyrBJuzYtjvyW6yDsg@public.gmane.org,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	inotify-tools-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Things I wish I'd known about Inotify
Date: Fri, 04 Apr 2014 10:50:29 -0400	[thread overview]
Message-ID: <1396623029.2608.15.camel@localhost> (raw)
In-Reply-To: <CANq1E4RzNA_ajEwf1rRbTa8xOP392_YfD0mShK6QV=FexoOpUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, 2014-04-04 at 15:00 +0200, David Herrmann wrote:

> 1)
> IN_IGNORED is async and _immediate_ in case a file got deleted. So if
> you use watch-descriptors as keys for your objects, an _already_ used
> key might be returned by inotify_add_watch() if an IN_IGNORED is
> queued for the old watch (which implicitly destroys the watch). Once
> you read the IN_IGNORED from the queue, there is usually no way to
> know whether it's generated by the old watch or by the new. The
> man-page mentions this in:
>   "IN_IGNORED:  Watch was removed explicitly (inotify_rm_watch(2)) or
>    automatically (file was deleted, or filesystem was unmounted)."
> I think we should add a note to BUGS that mentions this race (which is
> really not obvious from the description).
> 
> This race could be fixed by requiring an explicit inotify_rm_watch()
> if an IN_IGNORED was generated asynchronously.

For a brief while after the introduction of fsnotify this was a problem,
but not before then, or on anything remotely recent (like 4-5 years?).
We didn't re-use watch descriptors at all, so if you get a notification
after the IGNORED, its still the old one.  Today it's possible to wrap
around at INT_MAX and reuse, but that is a tee tiny issue...

----

Note that both of these races rely on watch-descriptors being reused
after they were freed. Turns out, that was "fixed" about exactly 1
year ago in:

commit a66c04b4534f9b25e1241dff9a9d94dff9fd66f8
Author: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date:   Mon Apr 29 16:21:21 2013 -0700

    inotify: convert inotify_add_to_idr() to use idr_alloc_cyclic()

So in case that was never backported, only older kernels are affected.
In newer kernels, wd reuse is quite unlikely. The races are still
there, though.

----

Actually that has nothing to do with it.  If anything, it reintroduces
the reuse since now it wraps instead of fails...

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Paris <eparis@redhat.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	Robert Love <rlove@rlove.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	linux-man <linux-man@vger.kernel.org>,
	gamin-list@gnome.org, lkml <linux-kernel@vger.kernel.org>,
	inotify-tools-general@lists.sourceforge.net
Subject: Re: Things I wish I'd known about Inotify
Date: Fri, 04 Apr 2014 10:50:29 -0400	[thread overview]
Message-ID: <1396623029.2608.15.camel@localhost> (raw)
In-Reply-To: <CANq1E4RzNA_ajEwf1rRbTa8xOP392_YfD0mShK6QV=FexoOpUA@mail.gmail.com>

On Fri, 2014-04-04 at 15:00 +0200, David Herrmann wrote:

> 1)
> IN_IGNORED is async and _immediate_ in case a file got deleted. So if
> you use watch-descriptors as keys for your objects, an _already_ used
> key might be returned by inotify_add_watch() if an IN_IGNORED is
> queued for the old watch (which implicitly destroys the watch). Once
> you read the IN_IGNORED from the queue, there is usually no way to
> know whether it's generated by the old watch or by the new. The
> man-page mentions this in:
>   "IN_IGNORED:  Watch was removed explicitly (inotify_rm_watch(2)) or
>    automatically (file was deleted, or filesystem was unmounted)."
> I think we should add a note to BUGS that mentions this race (which is
> really not obvious from the description).
> 
> This race could be fixed by requiring an explicit inotify_rm_watch()
> if an IN_IGNORED was generated asynchronously.

For a brief while after the introduction of fsnotify this was a problem,
but not before then, or on anything remotely recent (like 4-5 years?).
We didn't re-use watch descriptors at all, so if you get a notification
after the IGNORED, its still the old one.  Today it's possible to wrap
around at INT_MAX and reuse, but that is a tee tiny issue...

----

Note that both of these races rely on watch-descriptors being reused
after they were freed. Turns out, that was "fixed" about exactly 1
year ago in:

commit a66c04b4534f9b25e1241dff9a9d94dff9fd66f8
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Apr 29 16:21:21 2013 -0700

    inotify: convert inotify_add_to_idr() to use idr_alloc_cyclic()

So in case that was never backported, only older kernels are affected.
In newer kernels, wd reuse is quite unlikely. The races are still
there, though.

----

Actually that has nothing to do with it.  If anything, it reintroduces
the reuse since now it wraps instead of fails...


  parent reply	other threads:[~2014-04-04 14:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03  6:34 Things I wish I'd known about Inotify Michael Kerrisk (man-pages)
2014-04-03  6:34 ` Michael Kerrisk (man-pages)
     [not found] ` <CAKgNAkjymzawYMKZGedK=fai55cwo4p=yeYe6GT8MdxWON__zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-03 15:38   ` Eric W. Biederman
2014-04-03 15:38     ` Eric W. Biederman
2014-04-03 15:38     ` Eric W. Biederman
2014-04-04  7:59     ` Michael Kerrisk (man-pages)
2014-04-04  7:59       ` Michael Kerrisk (man-pages)
2014-04-04 20:24     ` Stef Bon
2014-04-03 20:52   ` Jan Kara
2014-04-03 20:52     ` Jan Kara
2014-04-04  7:35     ` Michael Kerrisk (man-pages)
     [not found]       ` <533E60D6.2000704-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-04 12:43         ` Jan Kara
2014-04-04 12:43           ` Jan Kara
2014-04-06  9:00           ` Michael Kerrisk (man-pages)
2014-04-06  9:00             ` Michael Kerrisk (man-pages)
     [not found]             ` <534117AD.1030708-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-07  9:31               ` Jan Kara
2014-04-07  9:31                 ` Jan Kara
     [not found]                 ` <20140407093152.GC14927-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
2014-04-12  5:44                   ` Michael Kerrisk (man-pages)
2014-04-12  5:44                     ` Michael Kerrisk (man-pages)
2014-07-12 19:06           ` Michael Kerrisk (man-pages)
2014-07-12 19:06             ` Michael Kerrisk (man-pages)
     [not found]             ` <CAKgNAkj=j2Auym+Euis0qYot3nYoASkeaf4kFPWvL-M-FCXEvQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-14 11:28               ` Jan Kara
2014-07-14 11:28                 ` Jan Kara
2014-07-15  4:15                 ` Michael Kerrisk (man-pages)
2014-07-15  4:15                   ` Michael Kerrisk (man-pages)
2014-04-04 13:00   ` David Herrmann
2014-04-04 13:00     ` David Herrmann
     [not found]     ` <CANq1E4RzNA_ajEwf1rRbTa8xOP392_YfD0mShK6QV=FexoOpUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-04 13:08       ` David Herrmann
2014-04-04 13:08         ` David Herrmann
2014-04-04 14:50       ` Eric Paris [this message]
2014-04-04 14:50         ` Eric Paris

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=1396623029.2608.15.camel@localhost \
    --to=eparis-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=gamin-list-rDKQcyrBJuzYtjvyW6yDsg@public.gmane.org \
    --cc=inotify-tools-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.