Extend fanotify dirent events

Jan,

This is the 2nd version of FAN_REPORT_TARGET_FID patches [1].

In the first version, extra info records about new and old parent+name
were added to FAN_MOVED_FROM event.  This version uses a new event
FAN_RENAME instead, to report those extra info records.
The new FAN_RENAME event was designed as a replacement for the
"inotify way" of joining the MOVED_FROM/MOVED_TO events using a cookie.

FAN_RENAME event differs from MOVED_FROM/MOVED_TO events in several ways:
1) The information about old/new names is provided in a single event
2) When added to the ignored mask of a directory, FAN_RENAME is not
   reported for renames to and from that directory

The group flag FAN_REPORT_TARGET_FID adds an extra info record of
the child fid to all the dirent events, including FAN_REANME.
It is independent of the FAN_RENAME changes and implemented in the
first patch, so it can be picked regardless of the FAN_RENAME patches.

Patches [2] and LTP test [3] are available on my github.
A man page draft will be provided later on.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/20211029114028.569755-1-amir73il@gmail.com/
[2] https://github.com/amir73il/linux/commits/fan_rename
[3] https://github.com/amir73il/ltp/commits/fan_rename

Amir Goldstein (9):
  fanotify: introduce group flag FAN_REPORT_TARGET_FID
  fsnotify: generate FS_RENAME event with rich information
  fanotify: use macros to get the offset to fanotify_info buffer
  fanotify: use helpers to parcel fanotify_info buffer
  fanotify: support secondary dir fh and name in fanotify_info
  fanotify: record old and new parent and name in FAN_RENAME event
  fanotify: record either old name new name or both for FAN_RENAME
  fanotify: report old and/or new parent+name in FAN_RENAME event
  fanotify: wire up FAN_RENAME event

16 more lines

On Fri, Nov 19, 2021 at 9:17 AM Amir Goldstein [off-list ref] wrote:

Jan,

This is the 2nd version of FAN_REPORT_TARGET_FID patches [1].

In the first version, extra info records about new and old parent+name
were added to FAN_MOVED_FROM event.  This version uses a new event
FAN_RENAME instead, to report those extra info records.
The new FAN_RENAME event was designed as a replacement for the
"inotify way" of joining the MOVED_FROM/MOVED_TO events using a cookie.

FAN_RENAME event differs from MOVED_FROM/MOVED_TO events in several ways:
1) The information about old/new names is provided in a single event
2) When added to the ignored mask of a directory, FAN_RENAME is not
   reported for renames to and from that directory

The group flag FAN_REPORT_TARGET_FID adds an extra info record of
the child fid to all the dirent events, including FAN_REANME.
It is independent of the FAN_RENAME changes and implemented in the
first patch, so it can be picked regardless of the FAN_RENAME patches.

Patches [2] and LTP test [3] are available on my github.
A man page draft will be provided later on.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/20211029114028.569755-1-amir73il@gmail.com/
[2] https://github.com/amir73il/linux/commits/fan_rename
[3] https://github.com/amir73il/ltp/commits/fan_rename

Here is a first man page draft [4].
It based on top of both FAN_REPORT_PIDFD and FAN_FS_ERROR patches.
I did not elaborate about the new info types yet in fanotify.7, because Matthew
was going to rephrase the entire section about fanotify_event_info_header.

Thanks,
Amir.

[4] https://github.com/amir73il/man-pages/commits/fan_rename

Hi Amir!

On Fri 19-11-21 09:17:29, Amir Goldstein wrote:

This is the 2nd version of FAN_REPORT_TARGET_FID patches [1].

In the first version, extra info records about new and old parent+name
were added to FAN_MOVED_FROM event.  This version uses a new event
FAN_RENAME instead, to report those extra info records.
The new FAN_RENAME event was designed as a replacement for the
"inotify way" of joining the MOVED_FROM/MOVED_TO events using a cookie.

FAN_RENAME event differs from MOVED_FROM/MOVED_TO events in several ways:
1) The information about old/new names is provided in a single event
2) When added to the ignored mask of a directory, FAN_RENAME is not
   reported for renames to and from that directory

The group flag FAN_REPORT_TARGET_FID adds an extra info record of
the child fid to all the dirent events, including FAN_REANME.
It is independent of the FAN_RENAME changes and implemented in the
first patch, so it can be picked regardless of the FAN_RENAME patches.

Patches [2] and LTP test [3] are available on my github.
A man page draft will be provided later on.

I've read through the series and I had just two small comments. I was also
slightly wondering whether instead of feeding the two directories for
FS_RENAME into OBJ_TYPE_PARENT and OBJ_TYPE_INODE we should not create
another iter_info type OBJ_TYPE_INODE2 as using OBJ_TYPE_PARENT is somewhat
error prone (you have to get the ordering of conditions right so that you
catch FS_RENAME e.g. before some code decides event should be discarded
because it is parent event without child watching). But I have not fully
decided whether the result is going to be worth it so I'm just mentioning
it as a possible future cleanup.

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR

On Fri, Nov 26, 2021 at 5:28 PM Jan Kara [off-list ref] wrote:

Hi Amir!

On Fri 19-11-21 09:17:29, Amir Goldstein wrote:

quoted

This is the 2nd version of FAN_REPORT_TARGET_FID patches [1].

In the first version, extra info records about new and old parent+name
were added to FAN_MOVED_FROM event.  This version uses a new event
FAN_RENAME instead, to report those extra info records.
The new FAN_RENAME event was designed as a replacement for the
"inotify way" of joining the MOVED_FROM/MOVED_TO events using a cookie.

FAN_RENAME event differs from MOVED_FROM/MOVED_TO events in several ways:
1) The information about old/new names is provided in a single event
2) When added to the ignored mask of a directory, FAN_RENAME is not
   reported for renames to and from that directory

The group flag FAN_REPORT_TARGET_FID adds an extra info record of
the child fid to all the dirent events, including FAN_REANME.
It is independent of the FAN_RENAME changes and implemented in the
first patch, so it can be picked regardless of the FAN_RENAME patches.

Patches [2] and LTP test [3] are available on my github.
A man page draft will be provided later on.

I've read through the series and I had just two small comments. I was also
slightly wondering whether instead of feeding the two directories for
FS_RENAME into OBJ_TYPE_PARENT and OBJ_TYPE_INODE we should not create
another iter_info type OBJ_TYPE_INODE2 as using OBJ_TYPE_PARENT is somewhat
error prone (you have to get the ordering of conditions right so that you
catch FS_RENAME e.g. before some code decides event should be discarded
because it is parent event without child watching). But I have not fully
decided whether the result is going to be worth it so I'm just mentioning
it as a possible future cleanup.

I managed to use ITER_TYPE_INODE2 pretty easily after a cleanup that
splits OBJ_TYPE enum from ITER_TYPE enum.

Thanks,
Amir.