summaryrefslogtreecommitdiffstats
path: root/fs/notify/mark.c
AgeCommit message (Collapse)AuthorFilesLines
2010-07-28fsnotify: remove global fsnotify groups listsEric Paris1-9/+0
The global fsnotify groups lists were invented as a way to increase the performance of fsnotify by shortcutting events which were not interesting. With the changes to walk the object lists rather than global groups lists these shortcuts are not useful. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: Exchange list heads instead of moving elementsAndreas Gruenbacher1-4/+2
Instead of moving list elements from destroy_list to &private_destroy_list, exchange the list heads. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: srcu to protect read side of inode and vfsmount locksEric Paris1-3/+57
Currently reading the inode->i_fsnotify_marks or vfsmount->mnt_fsnotify_marks lists are protected by a spinlock on both the read and the write side. This patch protects the read side of those lists with a new single srcu. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: use an explicit flag to indicate fsnotify_destroy_mark has been calledEric Paris1-4/+7
Currently fsnotify check is mark->group is NULL to decide if fsnotify_destroy_mark() has already been called or not. With the upcoming rcu work it is a heck of a lot easier to use an explicit flag than worry about group being set to NULL. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: call iput on inodes when no longer markedEric Paris1-1/+1
fsnotify takes an igrab on an inode when it adds a mark. The code was supposed to drop the reference when the mark was removed but didn't. This caused problems when an fs was unmounted because those inodes would clearly not be gone. Thus resulting in the most devistating of messages: VFS: Busy inodes after unmount of loop0. Self-destruct in 5 seconds. >>> Have a nice day... Jiri Slaby bisected the problem to a patch in the fsnotify tree. The code snippets below show my stupidity quite clearly. void fsnotify_destroy_inode_mark(struct fsnotify_mark *mark) { ... mark->inode = NULL; ... } void fsnotify_destroy_mark(struct fsnotify_mark *mark) { struct inode *inode = NULL; ... if (mark->flags & FSNOTIFY_MARK_FLAG_INODE) { fsnotify_destroy_inode_mark(mark); inode = mark->i.inode; } ... if (inode) iput(inode); ... } Obviously the intent was to capture the inode before it was set to NULL in fsnotify_destory_inode_mark() so we wouldn't be leaking inodes forever. Instead we leaked them (and exploded on umount) Reported-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fanotify: clear all fanotify marksEric Paris1-5/+16
fanotify listeners may want to clear all marks. They may want to do this to destroy all of their inode marks which have nothing but ignores. Realistically this is useful for av vendors who update policy and want to clear all of their cached allows. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: ignored_mask - excluding notificationEric Paris1-0/+6
The ignored_mask is a new mask which is part of fsnotify marks. A group's should_send_event() function can use the ignored mask to determine that certain events are not of interest. In particular if a group registers a mask including FS_OPEN on a vfsmount they could add FS_OPEN to the ignored_mask for individual inodes and not send open events for those inodes. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: allow marks to not pin inodes in coreEric Paris1-1/+16
inotify marks must pin inodes in core. dnotify doesn't technically need to since they are closed when the directory is closed. fanotify also need to pin inodes in core as it works today. But the next step is to introduce the concept of 'ignored masks' which is actually a mask of events for an inode of no interest. I claim that these should be liberally sent to the kernel and should not pin the inode in core. If the inode is brought back in the listener will get an event it may have thought excluded, but this is not a serious situation and one any listener should deal with. This patch lays the ground work for non-pinning inode marks by using lazy inode pinning. We do not pin a mark until it has a non-zero mask entry. If a listener new sets a mask we never pin the inode. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: vfsmount marks generic functionsEric Paris1-9/+11
Much like inode-mark.c has all of the code dealing with marks on inodes this patch adds a vfsmount-mark.c which has similar code but is intended for marks on vfsmounts. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: clear marks to 0 in fsnotify_init_markEric Paris1-4/+1
Currently fsnotify_init_mark sets some fields to 0/NULL. Some users already used some sorts of zalloc, some didn't. This patch uses memset to explicitly zero everything in the fsnotify_mark when it is initialized so we don't have to be careful if fields are later added to marks. Signed-off-by: Eric Paris <eparis@redhat.com>
2010-07-28fsnotify: split generic and inode specific mark codeEric Paris1-0/+294
currently all marking is done by functions in inode-mark.c. Some of this is pretty generic and should be instead done in a generic function and we should only put the inode specific code in inode-mark.c Signed-off-by: Eric Paris <eparis@redhat.com>