[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201008201438.16637.agruen@suse.de>
Date: Fri, 20 Aug 2010 14:38:14 +0200
From: Andreas Gruenbacher <agruen@...e.de>
To: Eric Paris <eparis@...hat.com>, linux-fsdevel@...r.kernel.org
Cc: Christoph Hellwig <hch@...radead.org>,
Matt Helsley <matthltc@...ibm.com>,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
Michael Kerrisk <michael.kerrisk@...il.com>
Subject: Re: [GIT PULL] notification tree - try 37!
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.
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists