|author||Eric Paris <firstname.lastname@example.org>||2009-12-17 21:24:23 -0500|
|committer||Eric Paris <email@example.com>||2010-07-28 09:58:52 -0400|
fsnotify: mount point listeners list and global mask
currently all of the notification systems implemented select which inodes they care about and receive messages only about those inodes (or the children of those inodes.) This patch begins to flesh out fsnotify support for the concept of listeners that want to hear notification for an inode accessed below a given monut point. This patch implements a second list of fsnotify groups to hold these types of groups and a second global mask to hold the events of interest for this type of group. The reason we want a second group list and mask is because the inode based notification should_send_event support which makes each group look for a mark on the given inode. With one nfsmount listener that means that every group would have to take the inode->i_lock, look for their mark, not find one, and return for every operation. By seperating vfsmount from inode listeners only when there is a inode listener will the inode groups have to look for their mark and take the inode lock. vfsmount listeners will have to grab the lock and look for a mark but there should be fewer of them, and one vfsmount listener won't cause the i_lock to be grabbed and released for every fsnotify group on every io operation. Signed-off-by: Eric Paris <firstname.lastname@example.org>
Diffstat (limited to 'fs/notify/inode_mark.c')
1 files changed, 7 insertions, 0 deletions
diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index a3230c48553..beffebb6462 100644
@@ -328,6 +328,13 @@ int fsnotify_add_mark(struct fsnotify_mark_entry *entry,
+ * XXX This is where we could also do the fsnotify_add_vfsmount_group
+ * if we are setting and vfsmount mark....
+ if (unlikely(list_empty(&group->vfsmount_group_list)))
* LOCKING ORDER!!!!