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! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
