fanotify issues in 2.6.34-rc6-next-20100506

fanotify issues in 2.6.34-rc6-next-20100506

[Anders Blomdell]

I have started to have a look at the fanotify system, based on information
gleaned from:

  [1] http://people.redhat.com/~eparis/fanotify/
  [2] http://lwn.net/Articles/360955/

Unfortunately there seems to be some bug in the current implemenation, since
running a patched version of the fanotify.c application found in [1]

--- fanotify.c.orig     2010-03-27 05:26:27.000000000 +0100
+++ fanotify.c  2010-05-07 10:56:38.000000000 +0200
@@ -125,7 +125,7 @@
                fan_mask |= FAN_ALL_PERM_EVENTS;

        // fanotify_init(flags, event_f_flags, priority)
-       fan_fd = fanotify_init(0, O_RDONLY | O_LARGEFILE, 0);
+       fan_fd = fanotify_init(0, 0, 0);
        if (fan_fd < 0)
                goto fail;

seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch'
and then running the command 'cd /dir/to/watch ; touch a b c d e f g h i j k l'
 might generate (results are more or less random):

/dir/to/watch/a: pid=18584 open
/dir/to/watch/a: pid=18584 close(writable)
/dir/to/watch/b: pid=18584 open                 # 2 open events for b
/dir/to/watch/b: pid=18584 open close(writable) #
/dir/to/watch/d: pid=18584 open                 # events for c missing
/dir/to/watch/d: pid=18584 open close(writable) # 2 open events for d
/dir/to/watch/f: pid=18584 open close(writable) # events for e missing
/dir/to/watch/g: pid=18584 open close(writable)
/dir/to/watch/h: pid=18584 open close(writable)
/dir/to/watch/i: pid=18584 open close(writable)
/dir/to/watch/j: pid=18584 open
/dir/to/watch/j: pid=18584 close(writable)
/dir/to/watch/k: pid=18584 open
/dir/to/watch/k: pid=18584 open close(writable) # 2 open events for k
/dir/to/watch/l: pid=18584 close(writable)      # no open event for l

A similar program using inotify gets all events correctly.


I have also problems with the fact that the following sequence dosn't leave a
trace in the fanotify events:

  mkdir /dir/not/watched
  touch /dir/not/watched/z
  ln /dir/not/watched/z /dir/to/watch/z
  rm /dir/not/watched/z
  rmdir /dir/not/watched)

What is the rationale for not reporting link/unlink events via fanotify?

Best regards

Anders Blomdell

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: fanotify issues in 2.6.34-rc6-next-20100506

[Eric Paris]

On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote:

> seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch'
> and then running the command 'cd /dir/to/watch ; touch a b c d e f g h i j k l'
>  might generate (results are more or less random):

I'm looking at it right now, not sure what's going on, probably screwed
up the even merging logic....

Re: fanotify issues in 2.6.34-rc6-next-20100506

[Eric Paris]

On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote:

> seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch'
> and then running the command 'cd /dir/to/watch ; touch a b c d e f g h i j k l'
>  might generate (results are more or less random):

sometimes I'm not the sharpest knife in the drawer.  switch statements
are hard.

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index bbcfccd..34c9661 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -21,6 +21,7 @@ static bool should_merge(struct fsnotify_event *old, struct fsnotify_event *new)
 			if ((old->path.mnt == new->path.mnt) &&
 			    (old->path.dentry == new->path.dentry))
 				return true;
+			break;
 		case (FSNOTIFY_EVENT_NONE):
 			return true;
 		default:

Re: fanotify issues in 2.6.34-rc6-next-20100506

[JohnG]

> On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote:
> ... switch statements are hard.

Two years passed, but this patch was never applied
and fanotify is as broken as it has been.
So, two questions:
- does anyone going to finally apply that patch (add "break" before case
(FSNOTIFY_EVENT_NONE) in should_merge)
- what is the status of fanotify? Does anybody still use it? Does it work (aside
from this bug?)

Just in case, I copied that old patch below:


diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index bbcfccd..34c9661 100644
a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -21,6 +21,7 @@ static bool should_merge(struct fsnotify_event *old, struct
fsnotify_event *new)
if ((old->path.mnt == new->path.mnt) &&
(old->path.dentry == new->path.dentry))
return true;
+ break;
case (FSNOTIFY_EVENT_NONE):
return true;
default: