Jan, In v1 there was only patch 1 [1] to allow FAN_PRE_ACCESS events on readdir (with FAN_ONDIR). Following your feedback on v1, v2 adds support for FAN_PATH_ACCESS event so that a non-populated directory could be populted either on first readdir or on first lookup. I am still tagging this as RFC for two semi-related reasons: 1) In my original draft of man-page for FAN_PATH_ACCESS [2], I had introduced a new class FAN_CLASS_PRE_PATH, which FAN_PATH_ACCESS requires and is defined as: "Unlike FAN_CLASS_PRE_CONTENT, this class can be used along with FAN_REPORT_DFID_NAME to report the names of the looked up files along with O_PATH file descriptos in the new path lookup events." I am not sure if we really need FAN_CLASS_PRE_PATH, so wanted to ask your opinion. The basic HSM (as implemented in my POC) does not need to get the lookup name in the event - it populates dir on first readdir or lookup access. So I think that support for (FAN_CLASS_PRE_CONTENT | FAN_REPORT_DFID_NAME) could be added later per demand. 2) Current code does not generate FAN_PRE_ACCESS from vfs internal lookup helpers such as lookup_one*() helpers from overalyfs and nfsd. This is related to the API of reporting an O_PATH event->fd for FAN_PATH_ACCESS event, which requires a mount. If we decide that we want to support FAN_PATH_ACCESS from all the path-less lookup_one*() helpers, then we need to support reporting FAN_PATH_ACCESS event with directory fid. If we allow FAN_PATH_ACCESS event from path-less vfs helpers, we still have to allow setting FAN_PATH_ACCESS in a mount mark/ignore mask, because we need to provide a way for HSM to opt-out of FAN_PATH_ACCESS events on its "work" mount - the path via which directories are populated. There may be a middle ground: - Pass optional path arg to __lookup_slow() (i.e. from walk_component()) - Move fsnotify hook into __lookup_slow() - fsnotify_lookup_perm() passes optional path data to fsnotify() - fanotify_handle_event() returns -EPERM for FAN_PATH_ACCESS without path data This way, if HSM is enabled on an sb and not ignored on specific dir after it was populated, path lookup from syscall will trigger FAN_PATH_ACCESS events and overalyfs/nfsd will fail to lookup inside non-populated directories. Supporting populate events from overalyfs/nfsd could be implemented later per demand by reporting directory fid instead of O_PATH fd. If you think that is worth checking, I can prepare a patch for the above so we can expose it to performance regression bots. Better yet, if you have no issues with the implementation in this patch set, maybe let it soak in for_next/for_testing as is to make sure that it does not already introduce any performance regressions. Thoughts? Amir. Changes since v1: - Jan's rewrite of patch 1 - Add support for O_PATH event->fd - Add FAN_PATH_ACCESS event [1] https://lore.kernel.org/all/20250402062707.1637811-1-amir73il@xxxxxxxxx/ [2] https://github.com/amir73il/man-pages/commits/fan_pre_path [3] https://github.com/amir73il/ltp/commits/fan_hsm/ Amir Goldstein (2): fanotify: allow O_PATH flag in event_f_flags fanotify: introduce FAN_PATH_ACCESS event Jan Kara (1): fanotify: allow creating FAN_PRE_ACCESS events on directories fs/namei.c | 70 +++++++++++++++++++++++++++--- fs/notify/fanotify/fanotify.c | 11 +++-- fs/notify/fanotify/fanotify_user.c | 11 +---- fs/notify/fsnotify.c | 2 +- fs/open.c | 4 +- include/linux/fanotify.h | 2 +- include/linux/fs.h | 10 +++-- include/linux/fsnotify.h | 28 +++++++++++- include/linux/fsnotify_backend.h | 4 +- include/linux/namei.h | 3 ++ include/uapi/linux/fanotify.h | 2 + 11 files changed, 116 insertions(+), 31 deletions(-) -- 2.34.1
