summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* inotify: allow users to request not to recieve events on unlinked childrenEric Paris2010-07-284-1/+12
| | | | | | | | | | | | | | 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-281-2/+5
| | | | | | | 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-281-0/+3
| | | | | | | 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-282-1/+1
| | | | | | | | | | 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-284-15/+7
| | | | | | The priority argument in fanotify is useless. Kill it. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: default Kconfig to nEric Paris2010-07-281-1/+1
| | | | | | | 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-281-1/+1
| | | | | | | | | | | 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-281-3/+5
| | | | | | | | | 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-281-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>
* fanotify: do not always return 0 in fsnotifyJean-Christophe Dubois2010-07-281-1/+1
| | | | | | | | 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-281-1/+1
| | | | | | | | 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-283-6/+184
| | | | | | | | 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-285-4/+99
| | | | | | | | | 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-285-30/+68
| | | | | | | | | | 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-282-3/+8
| | | | | | | | | | | 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-283-3/+2
| | | | | | | 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-285-15/+17
| | | | | | | | | | | 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-281-5/+16
| | | | | | | | | 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-285-8/+18
| | | | | | | | | | | | | 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-283-4/+41
| | | | | | | | | | | | | | | | 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-286-7/+46
| | | | | | | | | 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-282-1/+5
| | | | | | | | | 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-282-2/+5
| | | | | | | | 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>
* fsnotify: clear ignored mask on modifyEric Paris2010-07-281-0/+31
| | | | | | | | On inode modification we clear the ignored mask for all of the marks on the inode. This allows userspace to ignore accesses to inodes until there is something different. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: allow users to set an ignored_maskEric Paris2010-07-282-19/+39
| | | | | | | | | | Change the sys_fanotify_mark() system call so users can set ignored_masks on inodes. Remember, if a user new sets a real mask, and only sets ignored masks, the ignore will never be pinned in memory. Thus ignored_masks can be lost under memory pressure and the user may again get events they previously thought were ignored. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: ignored_mask to ignore eventsEric Paris2010-07-281-14/+23
| | | | | | | When fanotify receives an event it will check event->mask & ~ignored_mask. If no bits are left the event will not be sent. Signed-off-by: Eric Paris <eparis@redhat.com>
* fsnotify: ignored_mask - excluding notificationEric Paris2010-07-282-0/+9
| | | | | | | | | | | 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>
* fsnotify: allow marks to not pin inodes in coreEric Paris2010-07-287-21/+58
| | | | | | | | | | | | | | | | | 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>
* fanotify: remove outgoing function checks in fanotify.hAndreas Gruenbacher2010-07-283-16/+4
| | | | | | | | | A number of validity checks on outgoing data are done in static inlines but are only used in one place. Instead just do them where they are used for readability. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: remove fanotify.h declarationsAndreas Gruenbacher2010-07-283-47/+10
| | | | | | | | | fanotify_mark_validate functions are all needlessly declared in headers as static inlines. Instead just do the checks where they are needed for code readability. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: split fanotify_remove_markAndreas Gruenbacher2010-07-281-18/+27
| | | | | | | | split fanotify_remove_mark into fanotify_remove_inode_mark and fanotify_remove_vfsmount_mark. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: rename FAN_MARK_ON_VFSMOUNT to FAN_MARK_MOUNTAndreas Gruenbacher2010-07-282-4/+4
| | | | | | | the term 'vfsmount' isn't sensicle to userspace. instead call is 'mount. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: hooks the fanotify_mark syscall to the vfsmount codeEric Paris2010-07-282-5/+14
| | | | | | | | Create a new fanotify_mark flag which indicates we should attach the mark to the vfsmount holding the object referenced by dfd and pathname rather than the inode itself. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: remove fanotify_add_markAndreas Gruenbacher2010-07-281-22/+1
| | | | | | | fanotify_add_mark now does nothing useful anymore, drop it. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: do not return pointer from fanotify_add_*_markAndreas Gruenbacher2010-07-281-20/+16
| | | | | | | No need to return the mark from fanotify_add_*_mark to fanotify_add_mark Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: do not call fanotify_update_object_mask in fanotify_add_markAndreas Gruenbacher2010-07-281-94/+50
| | | | | | | | | Recalculate masks in fanotify_add_mark, don't use fanotify_update_object_mask. This gets us one step closers to readable code. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: do not call fanotify_update_object_mask in fanotify_remove_markAndreas Gruenbacher2010-07-281-4/+29
| | | | | | | | | Recalculate masks in fanotify_remove_mark, don't use fanotify_update_object_mask. This gets us one step closers to readable code. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: remove fanotify_update_markAndreas Gruenbacher2010-07-281-21/+10
| | | | | | | fanotify_update_mark() doesn't do much useful; remove it. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: infrastructure to add an remove marks on vfsmountsEric Paris2010-07-281-52/+133
| | | | | | | infrastructure work to add and remove marks on vfsmounts. This should get every set up except wiring the functions to the syscalls. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: should_send_event needs to handle vfsmountsEric Paris2010-07-282-11/+47
| | | | | | | | currently should_send_event in fanotify only cares about marks on inodes. This patch extends that interface to indicate that it cares about events that happened on vfsmounts. Signed-off-by: Eric Paris <eparis@redhat.com>
* fsnotify: Infrastructure for per-mount watchesAndreas Gruenbacher2010-07-285-0/+20
| | | | | | | | | Per-mount watches allow groups to listen to fsnotify events on an entire mount. This patch simply adds and initializes the fields needed in the vfsmount struct to make this happen. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fsnotify: vfsmount marks generic functionsEric Paris2010-07-285-10/+191
| | | | | | | | 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>
* fsnotify/vfsmount: add fsnotify fields to struct vfsmountAndreas Gruenbacher2010-07-283-4/+10
| | | | | | | | | | This patch adds the list and mask fields needed to support vfsmount marks. These are the same fields fsnotify needs on an inode. They are not used, just declared and we note where the cleanup hook should be (the function is not yet defined) Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fsnotify: clear marks to 0 in fsnotify_init_markEric Paris2010-07-281-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>
* fsnotify: split generic and inode specific mark codeEric Paris2010-07-2812-252/+347
| | | | | | | | 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>
* fanotify: Add pids to eventsAndreas Gruenbacher2010-07-285-2/+9
| | | | | | | | Pass the process identifiers of the triggering processes to fanotify listeners: this information is useful for event filtering and logging. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: create_fd cleanupAndreas Gruenbacher2010-07-281-11/+6
| | | | | | | | Code cleanup which does the fd creation work seperately from the userspace metadata creation. It fits better with the other code. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: CONFIG_HAVE_SYSCALL_WRAPPERS for sys_fanotify_markHeiko Carstens2010-07-281-2/+14
| | | | | | | | | | | | | | | | | Please note that you need the patch below in addition, otherwise the syscall wrapper stuff won't work on those 32 bit architectures which enable the wrappers. When enabled the syscall wrapper defines always take long parameters and then cast them to whatever is needed. This approach doesn't work for the 32 bit case where the original syscall takes a long long parameter, since we would lose the upper 32 bits. So syscalls with 64 bit arguments are special cases wrt to syscall wrappers and enp up in the ugliness below (see also sys_fallocate). In addition these special cased syscall wrappers have the drawback that ftrace syscall tracing doesn't work on them, since they don't get defined by using the usual macros. Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: select ANON_INODES.Paul Mundt2010-07-281-0/+1
| | | | | | | | | | | | | | | fanotify references anon_inode_getfd(), which is only available with ANON_INODES enabled. Presently this bails out with the following: LD vmlinux fs/built-in.o: In function `sys_fanotify_init': (.text+0x26d1c): undefined reference to `anon_inode_getfd' make: *** [vmlinux] Error 1 which is trivially corrected by adding an ANON_INODES select. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Eric Paris <eparis@redhat.com>
* fanotify: send events using readEric Paris2010-07-283-4/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Send events to userspace by reading the file descriptor from fanotify_init(). One will get blocks of data which look like: struct fanotify_event_metadata { __u32 event_len; __u32 vers; __s32 fd; __u64 mask; __s64 pid; __u64 cookie; } __attribute__ ((packed)); Simple code to retrieve and deal with events is below while ((len = read(fan_fd, buf, sizeof(buf))) > 0) { struct fanotify_event_metadata *metadata; metadata = (void *)buf; while(FAN_EVENT_OK(metadata, len)) { [PROCESS HERE!!] if (metadata->fd >= 0 && close(metadata->fd) != 0) goto fail; metadata = FAN_EVENT_NEXT(metadata, len); } } Signed-off-by: Eric Paris <eparis@redhat.com>
OpenPOWER on IntegriCloud