On Mon, Sep 3, 2018 at 11:49 AM Jan Kara <jack@xxxxxxx> wrote: > > On Fri 31-08-18 18:30:32, Amir Goldstein wrote: > > On Fri, Aug 31, 2018 at 5:05 PM Jan Kara <jack@xxxxxxx> wrote: > > > > > > On Thu 30-08-18 18:15:51, Amir Goldstein wrote: > > > > Add another mark type flag FAN_MARK_FILESYSTEM for add/remove/flush > > > > of super block mark type. > > > > > > > > A super block watch gets all events on the filesystem, regardless of > > > > the mount from which the mark was added, unless an ignore mask exists > > > > on either the inode or the mount where the event was generated. > > > > > > > > Only one of FAN_MARK_MOUNT and FAN_MARK_FILESYSTEM mark type flags > > > > may be provided to fanotify_mark() or no mark type flag for inode mark. > > > > > > > > Cc: <linux-api@xxxxxxxxxxxxxxx> > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > [...] > > Shall I go as far as: > > #define FAN_MARK_TYPE_BIT1 0x00000010 > > #define FAN_MARK_TYPE_BIT2 0x00000100 > > #define FAN_MARK_TYPE_MASK (FAN_MARK_TYPE_BIT1 | FAN_MARK_TYPE_BIT2) > > > > /* mark type can be a combination of mark type bits */ > > #define FAN_MARK_INODE 0 > > #define FAN_MARK_MOUNT FAN_MARK_TYPE_BIT1 > > #define FAN_MARK_FILESYSTEM FAN_MARK_TYPE_BIT2 > > Probably I would not go as far as defining FAN_MARK_TYPE_BIT?. That looks a > bit confusing and it's in userspace-visible headers. I'd just define the > mask and add it into FAN_ALL_MARK_FLAGS instead of FAN_MARK_MOUNT. That > should protect us (together with flags & supported-type checks in > do_fanotify_mark()) against messing up the definitions (at least I hope ;). > That's what I figured.. already posted v4 with a comment similar to that in the similar case of FAN_ALL_CLASS_BITS. Thanks, Amir.
