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 v2 0/9] Extend fanotify dirent events
Date: Mon, 29 Nov 2021 21:12:17 +0200	[thread overview]
Message-ID: <CAOQ4uxhRv=2q3K89QG3T=Xne4PLUpN_sh8R=+PZETUa9GEJt-A@mail.gmail.com> (raw)
In-Reply-To: <20211126152841.GK13004@quack2.suse.cz>

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.

      reply	other threads:[~2021-11-29 22:16 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
2021-11-29 19:12   ` Amir Goldstein [this message]

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='CAOQ4uxhRv=2q3K89QG3T=Xne4PLUpN_sh8R=+PZETUa9GEJt-A@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.