fanotify issues in 2.6.34-rc6-next-20100506

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]

@@ -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: [email protected]
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

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

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

index bbcfccd..34c9661 100644
@@ -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:

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:

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: