summaryrefslogtreecommitdiffstats
path: root/fs/notify/dnotify
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2009-12-17 21:24:23 -0500
committerEric Paris <eparis@redhat.com>2010-07-28 09:58:52 -0400
commit7131485a93679ff9a543b74df280cfd119eb03ca (patch)
treed5d635cb37f77ef7ff8942e15de4c45f3fded940 /fs/notify/dnotify
parent4ca763523e040dc61191d4866a82981a5d30a4e9 (diff)
downloadlinux-7131485a93679ff9a543b74df280cfd119eb03ca.tar.gz
linux-7131485a93679ff9a543b74df280cfd119eb03ca.tar.bz2
linux-7131485a93679ff9a543b74df280cfd119eb03ca.zip
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 <eparis@redhat.com>
Diffstat (limited to 'fs/notify/dnotify')
0 files changed, 0 insertions, 0 deletions