Is this a fanotify_init() bug manifesting in fanotify_mark()?

Is this a fanotify_init() bug manifesting in fanotify_mark()?

[Josh Marshall]

Hello all, I rarely post.  Please be gentle.

I am making an event driven free space monitoring utility.  The core
idea of the design is to use fanotify to listen for the existence of
events which can increase space consumption, and when this happens
check the remaining free space.  Extra functionality to make this not
face meltingly stupid are planned before I suggest anyone use it,
don't worry.

I am using the documentation here:
https://man7.org/linux/man-pages/man7/fanotify.7.html
https://man7.org/linux/man-pages/man2/fanotify_init.2.html
https://man7.org/linux/man-pages/man2/fanotify_mark.2.html

```Causes problem
  int f_notify = fanotify_init(FAN_CLASS_NOTIF, 0);
```
```No problem
  int f_notify = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_DFID_NAME, 0);
```
```Where it manifests
  if( fanotify_mark(f_notify, FAN_MARK_ADD | FAN_MARK_ONLYDIR,
FAN_CREATE , AT_FDCWD, mnt) == -1 ){...}
```

The documentation for fanotify_init() states that no flags are
required in the first argument.  However, doing so using the code
example in the first link to documentation results in an error, with
errno being set to EINVAL.  However, when an additional flag gets
added to fanotify_init() outside the top three flags for control,
there is no error.

For my use case, it seems unnecessary to add additional flags and have
additional work done that I'll never use but that leads me to believe
that this is a kernel bug and I'm not prepared to delve into that
without someone else checking that this is an actual bug and what I
should do to fix it.