linux/fs/notify
Eric Paris 4a148ba988 inotify: check filename before dropping repeat events
inotify drops events if the last event on the queue is the same as the
current event.  But it does 2 things wrong.  First it is comparing old->inode
with new->inode.  But after an event if put on the queue the ->inode is no
longer allowed to be used.  It's possible between the last event and this new
event the inode could be reused and we would falsely match the inode's memory
address between two differing events.

The second problem is that when a file is removed fsnotify is passed the
negative dentry for the removed object rather than the postive dentry from
immediately before the removal.  This mean the (broken) inotify tail drop code
was matching the NULL ->inode of differing events.

The fix is to check the file name which is stored with events when doing the
tail drop instead of wrongly checking the address of the stored ->inode.

Reported-by: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
2009-07-21 15:26:26 -04:00
..
dnotify fsnotify: use def_bool in kconfig instead of letting the user choose 2009-07-21 15:26:26 -04:00
inotify fsnotify: use def_bool in kconfig instead of letting the user choose 2009-07-21 15:26:26 -04:00
fsnotify.c inotify/dnotify: should_send_event shouldn't match on FS_EVENT_ON_CHILD 2009-06-11 14:57:54 -04:00
fsnotify.h fsnotify: generic notification queue and waitq 2009-06-11 14:57:53 -04:00
group.c fsnotify: generic notification queue and waitq 2009-06-11 14:57:53 -04:00
inode_mark.c fsnotify: allow groups to set freeing_mark to null 2009-06-11 14:57:55 -04:00
Kconfig fsnotify: use def_bool in kconfig instead of letting the user choose 2009-07-21 15:26:26 -04:00
Makefile fsnotify: add marks to inodes so groups can interpret how to handle those inodes 2009-06-11 14:57:53 -04:00
notification.c inotify: check filename before dropping repeat events 2009-07-21 15:26:26 -04:00