aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'for-linus' of git://git.infradead.org/users/eparis/notifyLinus Torvalds2010-08-10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.infradead.org/users/eparis/notify: (132 commits) fanotify: use both marks when possible fsnotify: pass both the vfsmount mark and inode mark fsnotify: walk the inode and vfsmount lists simultaneously fsnotify: rework ignored mark flushing fsnotify: remove global fsnotify groups lists fsnotify: remove group->mask fsnotify: remove the global masks fsnotify: cleanup should_send_event fanotify: use the mark in handler functions audit: use the mark in handler functions dnotify: use the mark in handler functions inotify: use the mark in handler functions fsnotify: send fsnotify_mark to groups in event handling functions fsnotify: Exchange list heads instead of moving elements fsnotify: srcu to protect read side of inode and vfsmount locks fsnotify: use an explicit flag to indicate fsnotify_destroy_mark has been called fsnotify: use _rcu functions for mark list traversal fsnotify: place marks on object in order of group memory address vfs/fsnotify: fsnotify_close can delay the final work in fput fsnotify: store struct file not struct path ... Fix up trivial delete/modify conflict in fs/notify/inotify/inotify.c.
| * fanotify: use both marks when possibleEric Paris2010-07-28
| | | | | | | | | | | | | | | | fanotify currently, when given a vfsmount_mark will look up (if it exists) the corresponding inode mark. This patch drops that lookup and uses the mark provided. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: pass both the vfsmount mark and inode markEric Paris2010-07-28
| | | | | | | | | | | | | | | | should_send_event() and handle_event() will both need to look up the inode event if they get a vfsmount event. Lets just pass both at the same time since we have them both after walking the lists in lockstep. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: walk the inode and vfsmount lists simultaneouslyEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | We currently walk the list of marks on an inode followed by the list of marks on the vfsmount. These are in order (by the memory address of the group) so lets walk them both together. Eventually we can pass both the inode mark and the vfsmount mark to helpers simultaneously. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: rework ignored mark flushingEric Paris2010-07-28
| | | | | | | | | | | | | | | | currently ignored_mark clearing is done in a seperate list traversal before the actual list traversal to send events. There is no need for this. Do them at the same time. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: remove global fsnotify groups listsEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | 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>
| * fsnotify: remove group->maskEric Paris2010-07-28
| | | | | | | | | | | | | | group->mask is now useless. It was originally a shortcut for fsnotify to save on performance. These checks are now redundant, so we remove them. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: remove the global masksEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | Because we walk the object->fsnotify_marks list instead of the global fsnotify groups list we don't need the fsnotify_inode_mask and fsnotify_vfsmount_mask as these were simply shortcuts in fsnotify() for performance. They are now extra checks, rip them out. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: cleanup should_send_eventEric Paris2010-07-28
| | | | | | | | | | | | | | | | The change to use srcu and walk the object list rather than the global fsnotify_group list means that should_send_event is no longer needed for a number of groups and can be simplified for others. Do that. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: use the mark in handler functionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | fanotify now gets a mark in the should_send_event and handle_event functions. Rather than look up the mark themselves fanotify should just use the mark it was handed. Signed-off-by: Eric Paris <eparis@redhat.com>
| * audit: use the mark in handler functionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | audit now gets a mark in the should_send_event and handle_event functions. Rather than look up the mark themselves audit should just use the mark it was handed. Signed-off-by: Eric Paris <eparis@redhat.com>
| * dnotify: use the mark in handler functionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | dnotify now gets a mark in the should_send_event and handle_event functions. Rather than look up the mark themselves dnotify should just use the mark it was handed. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: use the mark in handler functionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | inotify now gets a mark in the should_send_event and handle_event functions. Rather than look up the mark themselves inotify should just use the mark it was handed. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: send fsnotify_mark to groups in event handling functionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | With the change of fsnotify to use srcu walking the marks list instead of walking the global groups list we now know the mark in question. The code can send the mark to the group's handling functions and the groups won't have to find those marks themselves. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: Exchange list heads instead of moving elementsAndreas Gruenbacher2010-07-28
| | | | | | | | | | | | | | | | 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>
| * fsnotify: srcu to protect read side of inode and vfsmount locksEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | 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>
| * fsnotify: use an explicit flag to indicate fsnotify_destroy_mark has been calledEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | 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>
| * fsnotify: use _rcu functions for mark list traversalEric Paris2010-07-28
| | | | | | | | | | | | | | | | In preparation for srcu locking use all _rcu appropiete functions for mark list addition, removal, and traversal. The operations are still done under a spinlock at the end of this patch. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: place marks on object in order of group memory addressEric Paris2010-07-28
| | | | | | | | | | | | | | fsnotify_marks currently are placed on objects (inodes or vfsmounts) in arbitrary order. This patch places them in order of the group memory address. Signed-off-by: Eric Paris <eparis@redhat.com>
| * vfs/fsnotify: fsnotify_close can delay the final work in fputEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fanotify almost works like so: user context calls fsnotify_* function with a struct file. fsnotify takes a reference on the struct path user context goes about it's buissiness at some later point in time the fsnotify listener gets the struct path fanotify listener calls dentry_open() to create a file which userspace can deal with listener drops the reference on the struct path at some later point the listener calls close() on it's new file With the switch from struct path to struct file this presents a problem for fput() and fsnotify_close(). fsnotify_close() is called when the filp has already reached 0 and __fput() wants to do it's cleanup. The solution presented here is a bit odd. If an event is created from a struct file we take a reference on the file. We check however if the f_count was already 0 and if so we take an EXTRA reference EVEN THOUGH IT WAS ZERO. In __fput() (where we know the f_count hit 0 once) we check if the f_count is non-zero and if so we drop that 'extra' ref and return without destroying the file. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: store struct file not struct pathEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | Al explains that calling dentry_open() with a mnt/dentry pair is only garunteed to be safe if they are already used in an open struct file. To make sure this is the case don't store and use a struct path in fsnotify, always use a struct file. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: fsnotify_add_notify_event should return an eventEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | Rather than the horrific void ** argument and such just to pass the fanotify_merge event back to the caller of fsnotify_add_notify_event() have those things return an event if it was different than the event suggusted to be added. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: add pr_debug throughoutEric Paris2010-07-28
| | | | | | | | | | | | | | It can be hard to debug fsnotify since there are so few printks. Use pr_debug to allow for dynamic debugging. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: groups can specify their f_flags for new fdEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | Currently fanotify fds opened for thier listeners are done with f_flags equal to O_RDONLY | O_LARGEFILE. This patch instead takes f_flags from the fanotify_init syscall and uses those when opening files in the context of the listener. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: check to make sure all fsnotify bits are uniqueEric Paris2010-07-28
| | | | | | | | | | | | | | This patch adds a check to make sure that all fsnotify bits are unique and we cannot accidentally use the same bit for 2 different fsnotify event types. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: Fix mask checksJerome Marchand2010-07-28
| | | | | | | | | | | | | | | | The mask checks in inotify_update_existing_watch() and inotify_new_watch() are useless because inotify_arg_to_mask() sets FS_IN_IGNORED and FS_EVENT_ON_CHILD bits anyway. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: force inotify and fsnotify use same bitsEric Paris2010-07-28
| | | | | | | | | | | | | | | | inotify uses bits called IN_* and fsnotify uses bits called FS_*. These need to line up. This patch adds build time checks to make sure noone can change these bits so they are not the same. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: allow users to request not to recieve events on unlinked childrenEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | An inotify watch on a directory will send events for children even if those children have been unlinked. This patch add a new inotify flag IN_EXCL_UNLINK which allows a watch to specificy they don't care about unlinked children. This should fix performance problems seen by tasks which add a watch to /tmp and then are overrun with events when other processes are reading and writing to unlinked files they created in /tmp. https://bugzilla.kernel.org/show_bug.cgi?id=16296 Requested-by: Matthias Clasen <mclasen@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: send IN_UNMOUNT eventsEric Paris2010-07-28
| | | | | | | | | | | | | | Since the .31 or so notify rewrite inotify has not sent events about inodes which are unmounted. This patch restores those events. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify: fix inotify oneshot supportEric Paris2010-07-28
| | | | | | | | | | | | | | During the large inotify rewrite to fsnotify I completely dropped support for IN_ONESHOT. Reimplement that support. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: update gfp/slab.h includesTejun Heo2010-07-28
| | | | | | | | | | | | | | | | | | | | Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Eric Paris <eparis@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: drop the useless priority argumentEric Paris2010-07-28
| | | | | | | | | | | | The priority argument in fanotify is useless. Kill it. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: default Kconfig to nEric Paris2010-07-28
| | | | | | | | | | | | | | fanotify has default to y in linux-next since it's inception but default to n in the final push to Linus. Signed-off-by: Eric Paris <eparis@redhat.com>
| * inotify_user.c: make local symbol staticH Hartley Sweeten2010-07-28
| | | | | | | | | | | | | | | | | | | | | | The symbol inotify_max_user_watches is not used outside this file and should be static. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: John McCutchan <john@johnmccutchan.com> Cc: Robert Love <rlove@rlove.org> Cc: Eric Paris <eparis@parisplace.org> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: initialize mask in fsnotify_permEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | akpm got a warning the fsnotify_mask could be used uninitialized in fsnotify_perm(). It's not actually possible but his compiler complained about it. This patch just initializes it to 0 to shut up the compiler. Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: call iput on inodes when no longer markedEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * fanotify: do not always return 0 in fsnotifyJean-Christophe Dubois2010-07-28
| | | | | | | | | | | | | | | | It seems to me you are always returning 0 in fsnotify, when you should return the error (EPERM) returned by fanotify. Signed-off-by: Jean-Christophe DUBOIS <jcd@tribudubois.net> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: do not return 0 in a void functionEric Paris2010-07-28
| | | | | | | | | | | | | | | | remove_access_response() is supposed to have a void return, but was returning 0; Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: userspace interface for permission responsesEric Paris2010-07-28
| | | | | | | | | | | | | | | | fanotify groups need to respond to events which include permissions types. To do so groups will send a response using write() on the fanotify_fd they have open. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: permissions and blockingEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | This is the backend work needed for fanotify to support the new FS_OPEN_PERM and FS_ACCESS_PERM fsnotify events. This is done using the new fsnotify secondary queue. No userspace interface is provided actually respond to or request these events. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: new fsnotify hooks and events types for access decisionsEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | introduce a new fsnotify hook, fsnotify_perm(), which is called from the security code. This hook is used to allow fsnotify groups to make access control decisions about events on the system. We also must change the generic fsnotify function to return an error code if we intend these hooks to be in any way useful. Signed-off-by: Eric Paris <eparis@redhat.com>
| * sysctl extern cleanup: inotifyDave Young2010-07-28
| | | | | | | | | | | | | | | | | | | | | | Extern declarations in sysctl.c should be move to their own head file, and then include them in relavant .c files. Move inotify_table extern declaration to linux/inotify.h Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Eric Paris <eparis@redhat.com>
| * dnotify: move dir_notify_enable declarationAlexey Dobriyan2010-07-28
| | | | | | | | | | | | | | Move dir_notify_enable declaration to where it belongs -- dnotify.h . Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: use unsigned char * for dentry->d_name.nameEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | fsnotify was using char * when it passed around the d_name.name string internally but it is actually an unsigned char *. This patch switches fsnotify to use unsigned and should silence some pointer signess warnings which have popped out of xfs. I do not add -Wpointer-sign to the fsnotify code as there are still issues with kstrdup and strlen which would pop out needless warnings. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: use merge argument to determine actual event added to queueEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | fanotify needs to know the actual event added to queues so it can be correctly checked for return values from userspace. To do this we need to pass that information from the merger code back to the main even handling routine. Currently that information is unused, but it will be. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: intoduce a notification merge argumentEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | Each group can define their own notification (and secondary_q) merge function. Inotify does tail drop, fanotify does matching and drop which can actually allocate a completely new event. But for fanotify to properly deal with permissions events it needs to know the new event which was ultimately added to the notification queue. This patch just implements a void ** argument which is passed to the merge function. fanotify can use this field to pass the new event back to higher layers. Signed-off-by: Eric Paris <eparis@redhat.com> for fanotify to properly deal with permissions events
| * fsnotify: add group prioritiesEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces an ordering to fsnotify groups. With purely asynchronous notification based "things" implementing fsnotify (inotify, dnotify) ordering isn't particularly important. But if people want to use fsnotify for the basis of sycronous notification or blocking notification ordering becomes important. eg. A Hierarchical Storage Management listener would need to get its event before an AV scanner could get its event (since the HSM would need to bring the data in for the AV scanner to scan.) Typically asynchronous notification would want to run after the AV scanner made any relevant access decisions so as to not send notification about an event that was denied. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fanotify: clear all fanotify marksEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | 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>
| * fanotify: allow ignored_masks to survive modifyEric Paris2010-07-28
| | | | | | | | | | | | | | | | | | Some users may want to truely ignore an inode even if it has been modified. Say you are wanting a mount which contains a log file and you really don't want any notification about that file. This patch allows the listener to do that. Signed-off-by: Eric Paris <eparis@redhat.com>
| * fsnotify: allow ignored_mask to survive modificationEric Paris2010-07-28
| | | | | | | | | | | | | | | | Some inodes a group may want to never hear about a set of events even if the inode is modified. We add a new mark flag which indicates that these marks should not have their ignored_mask cleared on modification. Signed-off-by: Eric Paris <eparis@redhat.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-27 11:50:06 -0500