From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: Jan Kara <jack@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: FAN_OPEN_EXEC event and ignore mask
Date: Mon, 5 Nov 2018 20:06:06 +1100 [thread overview]
Message-ID: <20181105090605.GA21126@lithium.mbobrowski.org> (raw)
In-Reply-To: <20181105084147.GC6953@quack2.suse.cz>
On Mon, Nov 05, 2018 at 09:41:47AM +0100, Jan Kara wrote:
> On Sat 03-11-18 11:34:13, Matthew Bobrowski wrote:
> > On Fri, Nov 02, 2018 at 01:50:00PM +0100, Jan Kara wrote:
> > > On Thu 01-11-18 16:45:47, Amir Goldstein wrote:
> > > > Permission events cannot
> > > > be merged, but man page doesn't say anything about that.
> > > > It might be worth dropping a note about OPEN_EXEC_PERM
> > > > that it could be expected to appear together in the same permission
> > > > event with OPEN_PERM and user response will apply to both.
> > >
> > > Umm, I'd actually prefer if the OPEN_PERM and OPEN_EXEC_PERM events didn't
> > > get merged. The overhead is just an additional call to fsnotify() to find
> > > out one of the events is uninteresting (realistically, 99% of users will be
> > > looking OPEN_PERM or OPEN_EXEC_PERM but not both) and it just keeps things
> > > simple in the API. I understand that it may seem somewhat unexpected that
> > > single file open will generate two different fsnotify permission events
> > > (again 99% users won't observe this anyway) but if we start "merging"
> > > permission events I think we open more space for confusion - like when
> > > event arrives with some bits trimmed due to ignore mask masking bits out or
> > > what not. What do you think Amir?
> >
> > This is something that I was going to bring up in my response yesterday,
> > however I wasn't sure how you guys would take it. In my opinion, I think
> > if we did merge the two open permission events then it would be
> > contradicting with all the existing comments and code related to the
> > permission events that we have scattered around the API. Thus, I'm in
> > favour of adding the additional fsnotify()/fsnotify_parent() calls to
> > minimise any potential confusion in regards to permission events being
> > merged moving forward.
>
> Yes, so please update your patch adding FAN_OPEN_EXEC_PERM to send this
> event separately from FAN_OPEN_PERM. Thanks!
OK, great. I will send through the updated patch series shortly.
--
Matthew Bobrowski
next prev parent reply other threads:[~2018-11-05 18:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1540635951.git.mbobrowski@mbobrowski.org>
[not found] ` <6ffb239329a462a82f078b9a1e5e06255888b620.1540635951.git.mbobrowski@mbobrowski.org>
[not found] ` <CAOQ4uxhts4FX9YBRPOqUjh+vfgfnUT5wxfcPDbNV8itWXjw7uA@mail.gmail.com>
[not found] ` <20181028060133.GA8066@development.internal.lab>
[not found] ` <CAOQ4uxjyneJDZfjbRDiasA_YF6gj8_Nxoyh8MYZGYkjXFyfbtA@mail.gmail.com>
[not found] ` <20181028222358.GA3769@workstation>
[not found] ` <20181029134620.GF5988@quack2.suse.cz>
[not found] ` <CAOQ4uxg+6MOWLz6pP=S1P-XowF58BA7NvfYqdxTbusaE19QuyQ@mail.gmail.com>
[not found] ` <20181030002744.GA4214@workstation>
2018-10-30 9:17 ` FAN_OPEN_EXEC event and ignore mask Amir Goldstein
2018-10-31 10:39 ` Matthew Bobrowski
2018-11-01 14:45 ` Amir Goldstein
2018-11-02 11:36 ` Matthew Bobrowski
2018-11-02 12:26 ` Amir Goldstein
2018-11-02 12:50 ` Jan Kara
2018-11-02 13:43 ` Amir Goldstein
2018-11-05 8:40 ` Jan Kara
2018-11-03 0:34 ` Matthew Bobrowski
2018-11-05 8:41 ` Jan Kara
2018-11-05 9:06 ` Matthew Bobrowski [this message]
2018-11-05 12:27 ` Amir Goldstein
2018-11-05 12:37 ` Matthew Bobrowski
2018-11-06 13:08 ` Matthew Bobrowski
2018-11-06 13:45 ` Amir Goldstein
2018-11-06 13:47 ` Amir Goldstein
2018-11-06 20:40 ` Matthew Bobrowski
2018-11-06 21:15 ` Amir Goldstein
2018-11-06 22:23 ` Matthew Bobrowski
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=20181105090605.GA21126@lithium.mbobrowski.org \
--to=mbobrowski@mbobrowski.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.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 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).