kernel.git/fs/notify/fsnotify.c, branch linux-5.3.y

fsnotify: get rid of fsnotify_nameremove()

2019-06-20T12:47:54Z

For all callers of fsnotify_{unlink,rmdir}(), we made sure that d_parent and d_name are stable. Therefore, fsnotify_{unlink,rmdir}() do not need the safety measures in fsnotify_nameremove() to stabilize parent and name. We can now simplify those hooks and get rid of fsnotify_nameremove(). Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 18

2019-05-21T09:28:46Z

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program see the file copying if not write to the free software foundation 675 mass ave cambridge ma 02139 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 52 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Jilayne Lovejoy Reviewed-by: Steve Winslow Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190519154042.342335923@linutronix.de Signed-off-by: Greg Kroah-Hartman

Merge tag 'fsnotify_for_v5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

2019-05-13T22:08:16Z

Pull fsnotify fixes from Jan Kara: "Two fsnotify fixes" * tag 'fsnotify_for_v5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: fsnotify: fix unlink performance regression fsnotify: Clarify connector assignment in fsnotify_add_mark_list()

fsnotify: fix unlink performance regression

2019-05-09T10:44:00Z

__fsnotify_parent() has an optimization in place to avoid unneeded take_dentry_name_snapshot(). When fsnotify_nameremove() was changed not to call __fsnotify_parent(), we left out the optimization. Kernel test robot reported a 5% performance regression in concurrent unlink() workload. Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/20190505062153.GG29809@shao2-debian/ Link: https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@quack2.suse.cz/ Fixes: 5f02a8776384 ("fsnotify: annotate directory entry modification events") CC: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

fsnotify: switch send_to_group() and ->handle_event to const struct qstr *

2019-04-26T17:51:03Z

note that conditions surrounding accesses to dname in audit_watch_handle_event() and audit_mark_handle_event() guarantee that dname won't have been NULL. Signed-off-by: Al Viro

fsnotify(): switch to passing const struct qstr * for file_name

2019-04-26T17:37:25Z

Note that in fnsotify_move() and fsnotify_link() we are guaranteed that dentry->d_name won't change during the fsnotify() evaluation (by having the parent directory locked exclusive), so we don't need to fetch dentry->d_name.name in the callers. In fsnotify_dirent() the same stability of dentry->d_name is also true, but it's a bit more convoluted - there is one callchain (devpts_pty_new() -> fsnotify_create() -> fsnotify_dirent()) where the parent is _not_ locked, but on devpts ->d_name of everything is unchanging; it has neither explicit nor implicit renames. Signed-off-by: Al Viro

ovl_lookup_real_one(): don't bother with strlen()

2019-04-26T17:13:33Z

Signed-off-by: Al Viro

fsnotify: send all event types to super block marks

2019-02-06T14:20:30Z

So far, existence of super block marks was checked only on events with data type FSNOTIFY_EVENT_PATH. Use the super block of the "to_tell" inode to report the events of all event types to super block marks. This change has no effect on current backends. Soon, this will allow fanotify backend to receive all event types on a super block mark. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

fanotify: introduce new event mask FAN_OPEN_EXEC_PERM

2018-11-13T17:41:05Z

A new event mask FAN_OPEN_EXEC_PERM has been defined. This allows users to receive events and grant access to files that are intending to be opened for execution. Events of FAN_OPEN_EXEC_PERM type will be generated when a file has been opened by using either execve(), execveat() or uselib() system calls. This acts in the same manner as previous permission event mask, meaning that an access response is required from the user application in order to permit any further operations on the file. Signed-off-by: Matthew Bobrowski Reviewed-by: Amir Goldstein Signed-off-by: Jan Kara

fanotify: introduce new event mask FAN_OPEN_EXEC

2018-11-13T17:41:04Z

A new event mask FAN_OPEN_EXEC has been defined so that users have the ability to receive events specifically when a file has been opened with the intent to be executed. Events of FAN_OPEN_EXEC type will be generated when a file has been opened using either execve(), execveat() or uselib() system calls. The feature is implemented within fsnotify_open() by generating the FAN_OPEN_EXEC event type if __FMODE_EXEC is set within file->f_flags. Signed-off-by: Matthew Bobrowski Reviewed-by: Amir Goldstein Signed-off-by: Jan Kara