On Fri, 2010-08-20 at 14:38 +0200, Andreas Gruenbacher wrote: > On Friday 20 August 2010 05:50:36 Eric Paris wrote: > > We must be doing something different... What kernel? what kconfig? > > What exact FS setup? What exact steps are you taking? What programs > > are you using to test east side? > > I'm runnning 2.6.36-rc1, with CONFIG_FANOTIFY and > CONFIG_FANOTIFY_ACCESS_PERMISSIONS on apparently. I am watching the same > directory with inotify and fanotify at the same time, that is, with both an > inotify and an fanotify listener running in two separate processes. The > inotify listener is code I cannot send so easily, but I've shown the resulting > strace. The fanotify listener is the one from [1]. > > [1] http://git.kernel.org/?p=linux/kernel/git/agruen/fanotify-example.git > > Together with the traces I've provided this should give you way enough clues > to be able to look up in the code why listening for fanotify events apparently > causes a concurrent inotify listener to return an inotify event with struct > inotify_event->mask == 0 for each fanotify perm event. Spent a bit of the weekend trying to figure out what you were doing and couldn't reproduce it or find it in the code because I had already fixed it (albeit for slightly different reasons). The patch in question was: http://marc.info/?l=linux-kernel&m=128214903125780&w=2 the vfsmount_test_mask was always initialized but since no vfsmount marks were found it was never cleared. This left the code thinking that the given (inode) mark was interested in the event. I think you could reproduce it differently inotifywait -m -e open /mnt/tmp inotifywait -m -e close /mnt/tmp and you would get both event types for both watches. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
