Re: [PATCH v3 3/3] fanotify: add API to attach/detach super block mark

[Amir Goldstein <amir73il@gmail.com>]

On Mon, Sep 3, 2018 at 11:49 AM Jan Kara <jack@suse.cz> wrote:
>
> On Fri 31-08-18 18:30:32, Amir Goldstein wrote:
> > On Fri, Aug 31, 2018 at 5:05 PM Jan Kara <jack@suse.cz> 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@vger.kernel.org>
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > >
[...]
> > 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.