All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc: Jan Kara <jack@suse.cz>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v4 08/15] fanotify: enable FAN_REPORT_FID init flag
Date: Tue, 11 Dec 2018 08:58:22 +0200	[thread overview]
Message-ID: <CAOQ4uxg_v3Xwoc-hr9yU99f8Ns=sBGG+mviB-QLC38TgxcUQmA@mail.gmail.com> (raw)
In-Reply-To: <20181211061240.GA16052@lithium.mbobrowski.org>

On Tue, Dec 11, 2018 at 8:12 AM Matthew Bobrowski
<mbobrowski@mbobrowski.org> wrote:
>
> On Mon, Dec 10, 2018 at 05:20:38PM +0100, Jan Kara wrote:
> > On Sat 08-12-18 11:26:38, Amir Goldstein wrote:
> > > On Sun, Dec 2, 2018 at 1:38 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > >
> > > > When setting up an fanotify listener, user may request to get fid
> > > > information in event instead of an open file descriptor.
> > > >
> > > > The fid obtained with event on a watched object contains the file
> > > > handle returned by name_to_handle_at(2) and fsid returned by statfs(2).
> > > >
> > > > When setting a mark, we need to make sure that the filesystem
> > > > supports encoding file handles with name_to_handle_at(2) and that
> > > > statfs(2) encodes a non-zero fsid.
> > > >
> > >
> > > Jan,
> > >
> > > On a discussion with Matthew about tests he is writing for FAN_REPORT_TID,
> > > the issue of permission events came up.
> > > Since I am not aware of any specific benefit that FAN_REPORT_TID could
> > > bring to users of permission events, I think the best course of action is to
> > > limit the use of FAN_REPORT_TID to group with priority FAN_CLASS_NOTIF.
> > > That would simplify tests and man page and if we ever see a use case for
> > > anything else, we can add that in the future.
> > >
> > > If you agree, we should add something like this to this patch:
> >
> > Yeah, that's a good point. Agreed.
>
> OK, good to know. I will continue to write the FAN_REPORT_FID tests based on
> Amir's fanotify_dirent branch, which contains the amendment suggested below.
>
> Amir, presumably we should also have a separate test that covers the expected
> error result when FAN_REPORT_FID is supplied with invalid class bits?
>

Sure, that sounds good.
I also did not find any test coverage for expected error result when trying
to set permission mark bits on a FAN_CLASS_NOTIF group, so the same
test could be the home of this test case as well.
Going further to dirent events, we would also want to add validation
that dirent event cannot be set on mark for group without FAN_REPORT_FID
and cannot be set on a mount mark.

Thanks,
Amir.

  reply	other threads:[~2018-12-11  6:58 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-02 11:38 [PATCH v4 00/15] fanotify: add support for more event types Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 01/15] fsnotify: annotate directory entry modification events Amir Goldstein
2019-01-03 15:41   ` Jan Kara
2019-01-03 16:31     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 02/15] fsnotify: send all event types to super block marks Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 03/15] fsnotify: move mask out of struct fsnotify_event Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 04/15] fanotify: rename struct fanotify_{,perm_}event_info Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 05/15] fanotify: open code fill_event_metadata() Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 06/15] fanotify: encode file identifier for FAN_REPORT_FID Amir Goldstein
2019-01-03 16:18   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 07/15] fanotify: copy event fid info to user Amir Goldstein
2019-01-03 17:13   ` Jan Kara
2019-01-04  3:58     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 08/15] fanotify: enable FAN_REPORT_FID init flag Amir Goldstein
2018-12-08  9:26   ` Amir Goldstein
2018-12-10 16:20     ` Jan Kara
2018-12-11  6:12       ` Matthew Bobrowski
2018-12-11  6:58         ` Amir Goldstein [this message]
2018-12-02 11:38 ` [PATCH v4 09/15] fanotify: cache fsid in fsnotify_mark_connector Amir Goldstein
2019-01-04  9:38   ` Jan Kara
2019-01-04  9:54     ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 10/15] vfs: add vfs_get_fsid() helper Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 11/15] fanotify: use vfs_get_fsid() helper instead of vfs_statfs() Amir Goldstein
2019-01-04  9:55   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 12/15] fanotify: check FS_ISDIR flag instead of d_is_dir() Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 13/15] fanotify: support events with data type FSNOTIFY_EVENT_INODE Amir Goldstein
2019-01-04 10:17   ` Jan Kara
2019-01-04 11:12     ` Amir Goldstein
2018-12-02 11:38 ` [PATCH v4 14/15] fanotify: add support for create/attrib/move/delete events Amir Goldstein
2019-01-04 10:26   ` Jan Kara
2018-12-02 11:38 ` [PATCH v4 15/15] fanotify: report FAN_ONDIR to listener with FAN_REPORT_FID Amir Goldstein
2019-01-04 10:57   ` Jan Kara
2019-01-04 11:42     ` Amir Goldstein
2019-01-04 12:18       ` Jan Kara
2019-01-04 12:39         ` Amir Goldstein
2019-01-05  0:34           ` Matthew Bobrowski
2019-01-05  8:18             ` Amir Goldstein
2019-01-07  7:40         ` Amir Goldstein
2019-01-04 12:19       ` Jan Kara
2019-01-04 23:46       ` Matthew Bobrowski
2019-01-05  7:59         ` Amir Goldstein
2019-01-05  9:49           ` Matthew Bobrowski
2019-01-07  7:37             ` Amir Goldstein
2019-01-04 11:00 ` [PATCH v4 00/15] fanotify: add support for more event types Jan Kara
2019-01-07  7:46   ` Amir Goldstein
2019-01-09 14:02     ` Jan Kara
2019-01-09 15:34       ` Amir Goldstein
2019-01-10  7:49         ` Amir Goldstein
2019-01-10  9:22           ` Jan Kara
2019-01-10  9:50             ` Amir Goldstein
2019-01-10 11:43               ` Jan Kara
2019-01-10 11:55                 ` Amir Goldstein
2019-01-10  8:53         ` Jan Kara
2019-01-10 10:10           ` 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='CAOQ4uxg_v3Xwoc-hr9yU99f8Ns=sBGG+mviB-QLC38TgxcUQmA@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.