Re: [PATCH 0/7] Report more information in fanotify dirent events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 18, 2021 at 6:29 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Thu 18-11-21 14:47:18, Amir Goldstein wrote:
> > > > So let's say this - we can add support for OLD_DFID, NEW_DFID types
> > > > later if we think they may serve a purpose, but at this time, I see no
> > > > reason to complicate the UAPI anymore than it already is and I would
> > > > rather implement only:
> > > >
> > > > /* Info types for FAN_RENAME */
> > > > #define FAN_EVENT_INFO_TYPE_OLD_DFID_NAME       10
> > > > /* Reserved for FAN_EVENT_INFO_TYPE_OLD_DFID    11 */
> > > > #define FAN_EVENT_INFO_TYPE_NEW_DFID_NAME       12
> > > > /* Reserved for FAN_EVENT_INFO_TYPE_NEW_DFID    13 */
> > > >
> > > > Do you agree?
> > >
> > > I agree the utility of FAN_RENAME without FAN_REPORT_NAME is very limited
> > > so I'm OK with not implementing that at least for now.
> >
> > OK. The patches are staged at [1], but I ran into one more UAPI question
> > that I wanted to run by you before posting the patches.
> >
> > The question may be best described by the last commit on the tests branch [2]:
> >
> >     syscalls/fanotify16: Test FAN_RENAME with ignored mask
> >
> >     When a file is moved between two directories and only one of them is
> >     watching for FAN_RENAME events, the FAN_RENAME event will include only
> >     the information about the entry in the watched directory.
> >
> >     When one of the directories is watching FAN_RENAME, but the other is
> >     ignoring FAN_RENAME events, the FAN_RENAME event will not be reported
> >     at all.
> >
> >     This is not the same behavior as MOVED_FROM/TO events. User cannot
> >     request to ignore MOVED_FROM events according to destination directory
> >     nor MOVED_TO events according to source directory.
> >
> > I chose this behavior because I found it to be useful and consistent with
> > other behaviors involving ignored masks. Maybe "chose" is a strong word
> > here - I did not do anything to implement this specific behavior - it is just
> > how the code in fanotify_group_event_mask() works for merging masks
> > and ignored masks of different marks.
> >
> > Let me know if you approve of those ignored FAN_RENAME semantics
> > and I will post the patches for review.
>
> Yeah, I guess ignore masks with FAN_RENAME are going to be a bit
> non-intuitive either way and what you suggest makes sense. I suppose when
> SB has FAN_RENAME mark and either source or target have FAN_RENAME in the
> ignore mask, nothing will get reported as well, do it? If we are consistent
> like this, I guess fine by me.

Yes, that is correct, because the join of combined masks and combined
ignored_masks is done at the very end, if an event is in ignored mask of
any related mark, it will cause the drop of the event.

I will post patches soon.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux