linux.git/fs/inotify.c, branch master

filesystem notification: create fs/notify to contain all fs notification

2008-12-31T23:07:43+00:00

Creating a generic filesystem notification interface, fsnotify, which will be
used by inotify, dnotify, and eventually fanotify is really starting to
clutter the fs directory.  This patch simply moves inotify and dnotify into
fs/notify/inotify and fs/notify/dnotify respectively to make both current fs/
and future notification tidier.

Signed-off-by: Eric Paris 
Signed-off-by: Al Viro

inotify: fix IN_ONESHOT unmount event watcher

2008-12-10T16:01:53+00:00

On umount two event will be dispatched to watcher:

1: inotify_dev_queue_event(.., IN_UNMOUNT,..)
2: remove_watch(watch, dev)
    ->inotify_dev_queue_event(.., IN_IGNORED, ..)

But if watcher has IN_ONESHOT bit set then the watcher will be released
inside first event.  Which result in accessing invalid object later.  IMHO
it is not pure regression.  This bug wasn't triggered while initial
inotify interface testing phase because of another bug in IN_ONESHOT
handling logic :)

  commit ac74c00e499ed276a965e5b5600667d5dc04a84a
  Author: Ulisses Furquim 
  Date:   Fri Feb 8 04:18:16 2008 -0800
    inotify: fix check for one-shot watches before destroying them
    As the IN_ONESHOT bit is never set when an event is sent we must check it
    in the watch's mask and not in the event's mask.

TESTCASE:
mkdir mnt
mount -ttmpfs none mnt
mkdir mnt/d
./inotify mnt/d&
umount mnt ## << lockup or crash here

TESTSOURCE:
/* gcc -oinotify inotify.c */
#include 
#include 
#include 

int main(int argc, char **argv)
{
        char buf[1024];
        struct inotify_event *ie;
        char *p;
        int i;
        ssize_t l;

        p = argv[1];
        i = inotify_init();
        inotify_add_watch(i, p, ~0);

        l = read(i, buf, sizeof(buf));
        printf("read %d bytes\n", l);
        ie = (struct inotify_event *) buf;
        printf("event mask: %d\n", ie->mask);
	return 0;
}

Signed-off-by: Dmitri Monakhov 
Cc: John McCutchan 
Cc: Al Viro 
Cc: Robert Love 
Cc: Ulisses Furquim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Fix inotify watch removal/umount races

2008-11-15T20:26:44+00:00

Inotify watch removals suck violently.

To kick the watch out we need (in this order) inode->inotify_mutex and
ih->mutex.  That's fine if we have a hold on inode; however, for all
other cases we need to make damn sure we don't race with umount.  We can
*NOT* just grab a reference to a watch - inotify_unmount_inodes() will
happily sail past it and we'll end with reference to inode potentially
outliving its superblock.

Ideally we just want to grab an active reference to superblock if we
can; that will make sure we won't go into inotify_umount_inodes() until
we are done.  Cleanup is just deactivate_super().

However, that leaves a messy case - what if we *are* racing with
umount() and active references to superblock can't be acquired anymore?
We can bump ->s_count, grab ->s_umount, which will almost certainly wait
until the superblock is shut down and the watch in question is pining
for fjords.  That's fine, but there is a problem - we might have hit the
window between ->s_active getting to 0 / ->s_count - below S_BIAS (i.e.
the moment when superblock is past the point of no return and is heading
for shutdown) and the moment when deactivate_super() acquires
->s_umount.

We could just do drop_super() yield() and retry, but that's rather
antisocial and this stuff is luser-triggerable.  OTOH, having grabbed
->s_umount and having found that we'd got there first (i.e.  that
->s_root is non-NULL) we know that we won't race with
inotify_umount_inodes().

So we could grab a reference to watch and do the rest as above, just
with drop_super() instead of deactivate_super(), right? Wrong.  We had
to drop ih->mutex before we could grab ->s_umount.  So the watch
could've been gone already.

That still can be dealt with - we need to save watch->wd, do idr_find()
and compare its result with our pointer.  If they match, we either have
the damn thing still alive or we'd lost not one but two races at once,
the watch had been killed and a new one got created with the same ->wd
at the same address.  That couldn't have happened in inotify_destroy(),
but inotify_rm_wd() could run into that.  Still, "new one got created"
is not a problem - we have every right to kill it or leave it alone,
whatever's more convenient.

So we can use idr_find(...) == watch && watch->inode->i_sb == sb as
"grab it and kill it" check.  If it's been our original watch, we are
fine, if it's a newcomer - nevermind, just pretend that we'd won the
race and kill the fscker anyway; we are safe since we know that its
superblock won't be going away.

And yes, this is far beyond mere "not very pretty"; so's the entire
concept of inotify to start with.

Signed-off-by: Al Viro 
Acked-by: Greg KH 
Signed-off-by: Linus Torvalds

inotify: remove debug code

2008-02-06T18:41:07+00:00

The inotify debugging code is supposed to verify that the
DCACHE_INOTIFY_PARENT_WATCHED scalability optimisation does not result in
notifications getting lost nor extra needless locking generated.

Unfortunately there are also some races in the debugging code.  And it isn't
very good at finding problems anyway.  So remove it for now.

Signed-off-by: Nick Piggin 
Cc: Robert Love 
Cc: John McCutchan 
Cc: Jan Kara 
Cc: Yan Zheng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

inotify: fix race

2008-02-06T18:41:06+00:00

There is a race between setting an inode's children's "parent watched" flag
when placing the first watch on a parent, and instantiating new children of
that parent: a child could miss having its flags set by
set_dentry_child_flags, but then inotify_d_instantiate might still see
!inotify_inode_watched.

The solution is to set_dentry_child_flags after adding the watch.  Locking is
taken care of, because both set_dentry_child_flags and inotify_d_instantiate
hold dcache_lock and child->d_locks.

Signed-off-by: Nick Piggin 
Cc: Robert Love 
Cc: John McCutchan 
Cc: Jan Kara 
Cc: Yan Zheng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] new helper - inotify_evict_watch()

2007-10-21T06:37:38+00:00

Kicks the watch out without dropping it.  Called under ->inotify_mutex

Signed-off-by: Al Viro

[PATCH] new helper - inotify_clone_watch()

2007-10-21T06:37:32+00:00

Signed-off-by: Al Viro

Introduce a handy list_first_entry macro

2007-05-08T18:15:11+00:00

There are many places in the kernel where the construction like

   foo = list_entry(head->next, struct foo_struct, list);

are used.
The code might look more descriptive and neat if using the macro

   list_first_entry(head, type, member) \
             list_entry((head)->next, type, member)

Here is the macro itself and the examples of its usage in the generic code.
 If it will turn out to be useful, I can prepare the set of patches to
inject in into arch-specific code, drivers, networking, etc.

Signed-off-by: Pavel Emelianov 
Signed-off-by: Kirill Korotaev 
Cc: Randy Dunlap 
Cc: Andi Kleen 
Cc: Zach Brown 
Cc: Davide Libenzi 
Cc: John McCutchan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: john stultz 
Cc: Ram Pai 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] severing fs.h, radix-tree.h -> sched.h

2006-12-04T07:00:24+00:00

Signed-off-by: Al Viro

[PATCH] inotify (4/5): allow watch removal from event handler

2006-06-20T09:25:19+00:00

Allow callers to remove watches from their event handler via
inotify_remove_watch_locked().  This functionality can be used to
achieve IN_ONESHOT-like functionality for a subset of events in the
mask.

Signed-off-by: Amy Griffis 
Acked-by: Robert Love 
Acked-by: John McCutchan 
Signed-off-by: Al Viro