pm24.git/include/linux/fsnotify.h, branch v5.2-rc2

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 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

switch fsnotify_move() to passing const struct qstr * for old_name

2019-04-26T17:22:05Z

note that in the second (RENAME_EXCHANGE) call of fsnotify_move() in vfs_rename() the old_dentry->d_name is guaranteed to be unchanged throughout the evaluation of fsnotify_move() (by the fact that the parent directory is locked exclusive), so we don't need to fetch old_dentry->d_name.name in the caller. Signed-off-by: Al Viro

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

2019-04-26T17:13:33Z

Signed-off-by: Al Viro

fanotify: check FS_ISDIR flag instead of d_is_dir()

2019-02-07T15:38:36Z

All fsnotify hooks set the FS_ISDIR flag for events that happen on directory victim inodes except for fsnotify_perm(). Add the missing FS_ISDIR flag in fsnotify_perm() hook and let fanotify_group_event_mask() check the FS_ISDIR flag instead of checking if path argument is a directory. This is needed for fanotify support for event types that do not carry path information. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

fsnotify: report FS_ISDIR flag with MOVE_SELF and DELETE_SELF events

2019-02-07T15:38:35Z

We need to report FS_ISDIR flag with MOVE_SELF and DELETE_SELF events for fanotify, because fanotify API requires the user to explicitly request events on directories by FAN_ONDIR flag. inotify never reported IN_ISDIR with those events. It looks like an oversight, but to avoid the risk of breaking existing inotify programs, mask the FS_ISDIR flag out when reprting those events to inotify backend. We also add the FS_ISDIR flag with FS_ATTRIB event in the case of rename over an empty target directory. inotify did not report IN_ISDIR in this case, but it normally does report IN_ISDIR along with IN_ATTRIB event, so in this case, we do not mask out the FS_ISDIR flag. [JK: Simplify the checks in fsnotify_move()] Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

fsnotify: annotate directory entry modification events

2019-02-06T14:11:59Z

"dirent" events are referring to events that modify directory entries, such as create,delete,rename. Those events should always be reported on a watched directory, regardless if FS_EVENT_ON_CHILD is set on the watch mask. fsnotify_nameremove() and fsnotify_move() were modified to no longer set the FS_EVENT_ON_CHILD event bit. This is a semantic change to align with the "dirent" event definition. It has no effect on any existing backend, because dnotify, inotify and audit always requets the child events and fanotify does not get the delete,rename events. The fsnotify_dirent() helper is used instead of fsnotify_parent() to report a dirent event to dentry->d_parent without FS_EVENT_ON_CHILD and regardless if parent has the FS_EVENT_ON_CHILD bit set. Unlike fsnotify_parent(), fsnotify_dirent() assumes that dentry->d_name and dentry->d_parent are stable. For fsnotify_create()/fsnotify_mkdir(), this assumption is abviously correct. For fsnotify_nameremove(), it is less trivial, so we use dget_parent() and take_dentry_name_snapshot() to grab stable references. 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

fsnotify: refactor fsnotify_parent()/fsnotify() paired calls when event is on path

2018-11-13T17:41:04Z

A wrapper function fsnotify_path() has been defined to simplify the paired calls to fsnotify_parent()/fsnotify(). All hooks that made use these paired calls and passed FSNOTIFY_EVENT_PATH have been updated accordingly. Signed-off-by: Matthew Bobrowski Reviewed-by: Amir Goldstein Signed-off-by: Jan Kara