From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
Matthew Bobrowski <mbobrowski@mbobrowski.org>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v2 0/9] Extend fanotify dirent events
Date: Fri, 26 Nov 2021 16:28:41 +0100 [thread overview]
Message-ID: <20211126152841.GK13004@quack2.suse.cz> (raw)
In-Reply-To: <20211119071738.1348957-1-amir73il@gmail.com>
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 <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-11-26 15:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-19 7:17 [PATCH v2 0/9] Extend fanotify dirent events Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 1/9] fanotify: introduce group flag FAN_REPORT_TARGET_FID Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 2/9] fsnotify: generate FS_RENAME event with rich information Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 3/9] fanotify: use macros to get the offset to fanotify_info buffer Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 4/9] fanotify: use helpers to parcel " Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 5/9] fanotify: support secondary dir fh and name in fanotify_info Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 6/9] fanotify: record old and new parent and name in FAN_RENAME event Amir Goldstein
2021-11-26 14:44 ` Jan Kara
2021-11-19 7:17 ` [PATCH v2 7/9] fanotify: record either old name new name or both for FAN_RENAME Amir Goldstein
2021-11-26 15:14 ` Jan Kara
2021-11-29 19:15 ` Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 8/9] fanotify: report old and/or new parent+name in FAN_RENAME event Amir Goldstein
2021-11-19 7:17 ` [PATCH v2 9/9] fanotify: wire up " Amir Goldstein
2021-11-20 12:59 ` [PATCH v2 0/9] Extend fanotify dirent events Amir Goldstein
2021-11-26 15:28 ` Jan Kara [this message]
2021-11-29 19:12 ` 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=20211126152841.GK13004@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--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.