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
next prev parent 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).