On Fri 18-03-22 05:13:01, Amir Goldstein wrote: > On Thu, Mar 17, 2022 at 5:45 PM Jan Kara <jack@xxxxxxx> wrote: > > > > On Thu 17-03-22 16:34:43, Jan Kara wrote: > > > On Mon 07-03-22 17:57:40, Amir Goldstein wrote: > > > > Similar to inotify's IN_MARK_CREATE, adding an fanotify mark with flag > > > > FAN_MARK_CREATE will fail with error EEXIST if an fanotify mark already > > > > exists on the object. > > > > > > > > Unlike inotify's IN_MARK_CREATE, FAN_MARK_CREATE has to supplied in > > > > combination with FAN_MARK_ADD (FAN_MARK_ADD is like inotify_add_watch() > > > > and the behavior of IN_MARK_ADD is the default for fanotify_mark()). > > > > > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > > > > What I'm missing in this changelog is "why". Is it just about feature > > > parity with inotify? I don't find this feature particularly useful... > > > > OK, now I understand after reading patch 5/5. Hum, but I'm not quite happy > > about the limitation to non-existing mark as much as I understand why you > > need it. Let me think... > > > > Sorry for not articulating the problem better. > Let me write up the problem and maybe someone can come up with a better > solution than I did. > > The problem that I was trying to avoid with FAN_MARK_VOLATILE is similar > to an existing UAPI problem with FAN_MARK_IGNORED_SURV_MODIFY - > This flag can only be set and not cleared and when set it affects all the events > set in the mask prior to that time, leading to unpredictable results. > > Let's say a user sets FAN_CLOSE in ignored mask without _SURV_MODIFY > and later sets FAN_OPEN in ignored mask with _SURV_MODIFY. > Does the ignored mask now include FAN_CLOSE? That depends > whether or not FAN_MODIFY event took place between the two calls. Yeah, but with FAN_MARK_VOLATILE the problem also goes the other way around. If I set FAN_MARK_VOLATILE on some inode and later add something to a normal mask, I might be rightfully surprised when the mark gets evicted and thus I will not get events I'm expecting. Granted the application would be stepping on its own toes because marks are "merged" only for the same notification group but still it could be surprising and avoiding such mishaps would probably involve extra tracking on the application side. The problem essentially lies in mixing mark "flags" (ONDIR, ON_CHILD, VOLATILE, SURV_MODIFY) with mark mask. Mark operations with identical set of flags can be merged without troubles but once flags are different results of the merge are always "interesting". So far the consequences were mostly benign (getting more events than the application may have expected) but with FAN_MARK_VOLATILE we can also start loosing events and that is more serious. So far my thinking is that we either follow the path of possibly generating more events than necessary (i.e., any merge of two masks that do not both have FAN_MARK_VOLATILE set will clear FAN_MARK_VOLATILE) or we rework the whole mark API (and implementation!) to completely avoid these strange effects of flag merging. I don't like FAN_MARK_CREATE much because IMO it solves only half of the problem - when new mark with a flag wants to merge with an existing mark, but does not solve the other half when some other mark wants to merge to a mark with a flag. Thoughts? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
