On Thu 30-11-23 17:29:02, Amir Goldstein wrote:
> On Thu, Nov 30, 2023 at 4:25 PM Jan Kara <jack@xxxxxxx> wrote:
> > > @@ -530,6 +528,7 @@ struct fsnotify_mark {
> > > #define FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY 0x0100
> > > #define FSNOTIFY_MARK_FLAG_NO_IREF 0x0200
> > > #define FSNOTIFY_MARK_FLAG_HAS_IGNORE_FLAGS 0x0400
> > > +#define FSNOTIFY_MARK_FLAG_HAS_FSID 0x0800
> > > unsigned int flags; /* flags [mark->lock] */
> > > };
> >
> > So this flag is in fact private to fanotify notification framework. Either
> > we could just drop this flag and use
> >
> > FANOTIFY_MARK(mark)->fsid[0] != 0 || FANOTIFY_MARK(mark)->fsid[1] != 0
>
> Cannot.
> Zero fsid is now a valid fsid in an inode mark (e.g. fuse).
> The next patch also adds the flag FSNOTIFY_MARK_FLAG_WEAK_FSID
Yeah, I've realized that once I've digested the second patch.
> > instead or we could at least add a comment that this flags is in fact
> > private to fanotify?
>
> There is already a comment, because all the flags above are fanotify flags:
>
> /* fanotify mark flags */
> #define FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY 0x0100
> #define FSNOTIFY_MARK_FLAG_NO_IREF 0x0200
> #define FSNOTIFY_MARK_FLAG_HAS_IGNORE_FLAGS 0x0400
Right, I should have checked more that the diff context ;) Sorry for the
noise.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
