| Message ID | 20211119071738.1348957-1-amir73il@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Extend fanotify dirent events | expand |
On Fri, Nov 19, 2021 at 9:17 AM Amir Goldstein <amir73il@gmail.com> 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
On Fri, Nov 26, 2021 at 5:28 PM Jan Kara <jack@suse.cz> wrote: > > 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. I managed to use ITER_TYPE_INODE2 pretty easily after a cleanup that splits OBJ_TYPE enum from ITER_TYPE enum. Thanks, Amir.