linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	Steve Grubb <sgrubb@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC
Date: Wed, 3 Oct 2018 18:33:43 +0200	[thread overview]
Message-ID: <20181003163343.GJ24030@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxgM7tvtFo6gs62VtUFiJg3DXeTTKuv2f+YvXCmBE4x-Dg@mail.gmail.com>

On Wed 03-10-18 19:18:27, Amir Goldstein wrote:
> On Wed, Oct 3, 2018 at 6:40 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Tue 02-10-18 13:37:13, Amir Goldstein wrote:
> [...]
> > > I am in fact in leaning to the former (as Mathew implemented it), because
> > > I am looking at inotify and my effort to add the "dentry" events to fanotify.
> > > First, my proposal suggests to report the optional event flag FAN_ONDIR,
> > > just like inotify does.
> >
> > Well, we already do deliver FAN_ONDIR event flag if the event was on
> > directory AFAIK. Just with fanotify you also have to explicitely ask for
> > events on directories to be delivered by setting FAN_ONDIR in the mark's
> > mask.
> >
> 
> We actually mask it in out fanotify, so in inotify, it is out-only and
> in fanotify, it is in-only.

OK, didn't notice that. Thanks for educating me.

> BTW, I could not help cleaning up that horrible FAN_MARK_ONDIR
> and it won us a very nice optimization of directory access events.
> patches to follow soon.

Cool! Less work for me as I also had tingling in my fingers to clean up
that mess, just didn't get to it yet :).

> > If that's your concern, what if we just masked out all
> > "unwanted" events in fanotify_handle_event()? fanotify_should_send_event()
> > does all the masking anyway so it's not like we'd loose any performance
> > with that and with current set of fanotify events it would be completely
> > transparent.
> >
> 
> I though about this first, but got myself confused thinking it would be messy.
> Now I am looking again and don't understand why.
> 
> I will try to sum up the solution for us and for Mathew:
> - No FAN_ENABLE_EXEC (sorry for that detour)
> - Implementation in fsnotify_open() is exactly as Mathew did it, but
> changing the
>   name of the flag to FS_OPEN_EXEC
> - Add FAN_OPEN_EXEC to valid user events mask and valid outgoing events
> - fanotify_should_send_event() returns the mask  to be reported in the event
> -- s/return false/return 0/
> -- return event_mask & FAN_ALL_OUTGOING_EVENTS & marks_mask &
>                                  ~marks_ignored_mask;
> 
> So we won't report events that user did not set a mask for and we won't report
> events that user has set an ignore mask for.

Exactly. Just I'd do the change to fanotify_should_send_event() as a
separate patch and rename that function to something like
fanotify_group_event_mask() or something like that to better express what
it will do.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2018-10-03 23:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-27 13:05 [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Matthew Bobrowski
2018-09-27 13:57 ` Amir Goldstein
2018-09-28  1:27   ` Matthew Bobrowski
2018-09-28  5:39     ` Amir Goldstein
2018-10-01  8:21       ` Matthew Bobrowski
2018-10-01  9:13         ` Amir Goldstein
2018-10-01 10:58 ` Jan Kara
2018-10-01 14:01   ` Amir Goldstein
2018-10-02  9:24     ` Jan Kara
2018-10-02 10:37       ` Amir Goldstein
2018-10-03 15:40         ` Jan Kara
2018-10-03 16:18           ` Amir Goldstein
2018-10-03 16:33             ` Jan Kara [this message]
2018-10-03 20:45               ` Matthew Bobrowski
2018-10-07 11:13               ` Matthew Bobrowski
2018-10-07 13:40                 ` Amir Goldstein
2018-10-08  9:35                 ` Jan Kara
2018-10-02 11:50       ` Matthew Bobrowski
2018-10-03 15:45         ` Jan Kara
2018-10-01 11:06 ` Jan Kara

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=20181003163343.GJ24030@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=sgrubb@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).