From: Eric Paris <eparis@redhat.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Matt Helsley <matthltc@us.ibm.com>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
Michael Kerrisk <michael.kerrisk@gmail.com>
Subject: Re: [GIT PULL] notification tree - try 37!
Date: Thu, 19 Aug 2010 23:50:36 -0400 [thread overview]
Message-ID: <1282276236.21419.2101.camel@acb20005.ipt.aol.com> (raw)
In-Reply-To: <201008192307.32526.agruen@suse.de>
On Thu, 2010-08-19 at 23:07 +0200, Andreas Gruenbacher wrote:
> On Thursday 19 August 2010 22:42:45 Eric Paris wrote:
[necessary context to the conversation reinserted]
>>> Watching the same directory with fanotify results in:
>>>
>>> .../d: pid=... open_perm
>>> .../d: pid=... open
>>> .../d: pid=... access_perm
>>> .../d: pid=... access_perm
>>> .../d: pid=... close
>>>
>>> Five events seem a bit excessive; I can't explain why so many are generated.
>>> The real issue is when watching the same directory both with inotify and
>>> fanotify, though: the fanotify result stays the same, but
> > The extra events are plainly the new events that inotify doesn't
> > support: namely permissions events. You ask for and received extra
> > events....
>
> How can it make sense that inotify suddenly starts seeing events it does not
> support?
I inline commented in the wrong place to make it clear what I was
responding to. The question I was was answering was: "Five events seem
a bit excessive; I can't explain why so many are generated." I answered
it.
Now onto the the question of extra inotify events:
> > I can't reproduce it. You must have some other testing methodology.....
>
> Apparently. Here is a trace if what I'm getting through inotify (the inotify
> events were dumped with gdb, the rest is from strace):
>
> inotify_init() = 3
> inotify_add_watch(3, "d", IN_ACCESS|IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_CLOSE_NOWRITE|IN_OPEN|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|
> IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF) = 1
> read(3, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0 \0\0@\0\0\0\0\0\0\0\0", 4210688) = 32
>
> => {wd = 1, mask = 0, cookie = 0, len = 0, name = ...}
> => {wd = 1, mask = 1073741856, cookie = 0, len = 0, name = ...}
>
> read(3, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\20\0\0@\0\0\0\0\0\0\0\0", 4210688) = 32
>
> => {wd = 1, mask = 0, cookie = 0, len = 0, name = ...}
> => {wd = 1, mask = 1073741840, cookie = 0, len = 0, name = ...}
>
> read(3, 0x7fff56db15e0, 4210688) = -1 EINTR (Interrupted system call)
inotify_add_watch(3, "/mnt/tmp/", IN_ACCESS|IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_CLOSE_NOWRITE|IN_OPEN|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF) = 1
lstat("/mnt/tmp/", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
write(2, "Watches established.\n", 21) = 21
select(4, [3], NULL, NULL, NULL) = 1 (in [3])
ioctl(3, FIONREAD, [16]) = 0
read(3, "\1\0\0\0 \0\0@\0\0\0\0\0\0\0\0", 65536) = 16
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8fef0d3000
write(1, "/mnt/tmp/ OPEN,ISDIR \n", 22) = 22
select(4, [3], NULL, NULL, NULL) = 1 (in [3])
ioctl(3, FIONREAD, [16]) = 0
read(3, "\1\0\0\0\20\0\0@\0\0\0\0\0\0\0\0", 65536) = 16
write(1, "/mnt/tmp/ CLOSE_NOWRITE,CLOSE,IS"..., 37) = 37
select(4, [3], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
+++ killed by SIGINT +++
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? If you want to spam me with something
I added a whole lot of pr_debug statements throughout notification code
just in case it wasn't perfect (haha) so if you built with dynamic debug
you could run my debug script:
#!/bin/bash
echo "file fs/notify/inode_mark.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/mark.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/notification.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/fanotify/fanotify_user.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/fanotify/fanotify.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/vfsmount_mark.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/group.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/inotify/inotify_fsnotify.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/inotify/inotify_user.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/dnotify/dnotify.c +p" > /sys/kernel/debug/dynamic_debug/control
echo "file fs/notify/fsnotify.c +p" > /sys/kernel/debug/dynamic_debug/control
reproduce and send me the dmesg results. Maybe I can glean something
out of it....
-Eric
next prev parent reply other threads:[~2010-08-20 3:51 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 15:58 Eric Paris
2010-08-06 23:34 ` Matt Helsley
2010-08-07 0:06 ` Christoph Hellwig
2010-08-07 19:15 ` Eric Paris
2010-08-07 20:55 ` Matt Helsley
2010-08-16 20:32 ` Andreas Gruenbacher
2010-08-17 3:39 ` Eric Paris
2010-08-17 4:03 ` Matt Helsley
2010-08-17 8:09 ` Andreas Gruenbacher
2010-08-17 15:08 ` Eric Paris
2010-08-19 20:24 ` Andreas Gruenbacher
2010-08-19 20:32 ` Andreas Gruenbacher
2010-08-19 20:42 ` Eric Paris
2010-08-19 21:07 ` Andreas Gruenbacher
2010-08-19 21:22 ` Andreas Gruenbacher
2010-08-20 3:50 ` Eric Paris [this message]
2010-08-20 12:38 ` Andreas Gruenbacher
2010-08-23 16:46 ` Eric Paris
2010-08-23 22:38 ` Andreas Gruenbacher
2010-08-20 0:00 ` Andreas Gruenbacher
2010-08-17 8:38 ` Andreas Gruenbacher
2010-08-17 15:24 ` Eric Paris
2010-08-17 15:48 ` Andreas Gruenbacher
2010-08-18 14:18 ` Andreas Gruenbacher
2010-08-17 9:45 ` Tvrtko Ursulin
2010-08-17 10:01 ` Andreas Gruenbacher
2010-08-17 10:12 ` Tvrtko Ursulin
2010-08-17 10:55 ` Tvrtko Ursulin
2010-08-17 15:27 ` Eric Paris
2010-08-18 15:47 ` [GIT PULL] notification tree: directory events Andreas Gruenbacher
2010-08-18 15:59 ` Eric Paris
2010-08-18 16:42 ` Christoph Hellwig
2010-08-18 17:07 ` Eric Paris
2010-08-19 12:44 ` Andreas Gruenbacher
2010-08-19 15:00 ` Eric Paris
2010-08-19 23:41 ` Andreas Gruenbacher
2010-08-20 3:38 ` Eric Paris
2010-08-20 5:19 ` Andreas Dilger
2010-08-20 9:21 ` Christoph Hellwig
2010-08-20 15:29 ` Andreas Gruenbacher
2010-08-20 20:39 ` Andreas Dilger
2010-08-20 9:09 ` Tvrtko Ursulin
2010-08-20 11:07 ` Andreas Gruenbacher
2010-08-20 11:25 ` Andreas Gruenbacher
2010-08-20 12:16 ` Andreas Gruenbacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1282276236.21419.2101.camel@acb20005.ipt.aol.com \
--to=eparis@redhat.com \
--cc=agruen@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=michael.kerrisk@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome