All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH 0/7] Report more information in fanotify dirent events
Date: Thu, 18 Nov 2021 14:47:18 +0200	[thread overview]
Message-ID: <CAOQ4uxgfCmWCt=NNxj53+eKtVE-FMWBDNgFuQpGiFooZpne6zw@mail.gmail.com> (raw)
In-Reply-To: <20211116101232.GA23464@quack2.suse.cz>

> > 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.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fan_rename
[2] https://github.com/amir73il/ltp/commits/fan_rename

  reply	other threads:[~2021-11-18 12:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 11:40 [PATCH 0/7] Report more information in fanotify dirent events Amir Goldstein
2021-10-29 11:40 ` [PATCH 1/7] fsnotify: pass dentry instead of inode data for move events Amir Goldstein
2021-10-29 11:40 ` [PATCH 2/7] fanotify: introduce group flag FAN_REPORT_TARGET_FID Amir Goldstein
2021-10-29 11:40 ` [PATCH 3/7] fanotify: use macros to get the offset to fanotify_info buffer Amir Goldstein
2021-10-29 11:40 ` [PATCH 4/7] fanotify: support secondary dir fh and name in fanotify_info Amir Goldstein
2021-10-29 11:40 ` [PATCH 5/7] fanotify: record new parent and name in MOVED_FROM event Amir Goldstein
2021-11-12 16:48   ` Jan Kara
2021-11-13  9:40     ` Amir Goldstein
2021-11-15  8:18       ` Jan Kara
2021-10-29 11:40 ` [PATCH 6/7] fanotify: report " Amir Goldstein
2021-10-29 11:40 ` [PATCH 7/7] fanotify: enable the FAN_REPORT_TARGET_FID flag Amir Goldstein
2021-11-06 16:29 ` [PATCH 0/7] Report more information in fanotify dirent events Amir Goldstein
2021-11-12 16:39   ` Jan Kara
2021-11-13  9:49     ` Amir Goldstein
2021-11-13 19:31       ` Amir Goldstein
2021-11-15 10:23         ` Jan Kara
2021-11-15 12:22           ` Amir Goldstein
2021-11-15 14:37             ` Jan Kara
2021-11-16  6:59               ` Amir Goldstein
2021-11-16 10:12                 ` Jan Kara
2021-11-18 12:47                   ` Amir Goldstein [this message]
2021-11-18 16:29                     ` Jan Kara
2021-11-18 16:43                       ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOQ4uxgfCmWCt=NNxj53+eKtVE-FMWBDNgFuQpGiFooZpne6zw@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.