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. -- Matthew Bobrowski <mbobrowski@xxxxxxxxxxxxxx>
