user/sven/linux.git/include/linux/fsnotify.h, branch v5.4.90

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

fsnotify: move fsnotify_nameremove() hook out of d_delete()

2019-06-20T12:47:44Z

d_delete() was piggy backed for the fsnotify_nameremove() hook when in fact not all callers of d_delete() care about fsnotify events. For all callers of d_delete() that may be interested in fsnotify events, we made sure to call one of fsnotify_{unlink,rmdir}() hooks before calling d_delete(). Now we can move the fsnotify_nameremove() call from d_delete() to the fsnotify_{unlink,rmdir}() hooks. Two explicit calls to fsnotify_nameremove() from nfs/afs sillyrename are also removed. This will cause a change of behavior - nfs/afs will NOT generate an fsnotify delete event when renaming over a positive dentry. This change is desirable, because it is consistent with the behavior of all other filesystems. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

fsnotify: add empty fsnotify_{unlink,rmdir}() hooks

2019-06-20T12:44:55Z

We would like to move fsnotify_nameremove() calls from d_delete() into a higher layer where the hook makes more sense and so we can consider every d_delete() call site individually. Start by creating empty hook fsnotify_{unlink,rmdir}() and place them in the proper VFS call sites. After all d_delete() call sites will be converted to use the new hook, the new hook will generate the delete events and fsnotify_nameremove() hook will be removed. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara

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