[RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Amir Goldstein]

A new flavor of FAN_MARK_IGNORED_MASK that helps to resolve the
ambiguity around the combination of event flags and ignore mask.

It is also more strict in the events and flags allowed to be
set in a non-directory inode mark mask and it mandates the use
of FAN_MARK_IGNORED_SURV_MODIFY flag on filesystem, mount and
directory inode marks.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---

Hi Alex,

This is an update for a new fanotify feature merged to v6.0-rc1.
I am posting this man page update for early review.

You would probably want to wait for v6.0 release before merging
this anyway.

Thanks,
Amir.

 man2/fanotify_mark.2 | 147 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 146 insertions(+), 1 deletion(-)

diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
index 757ad9159..e9303827c 100644
--- a/man2/fanotify_mark.2
+++ b/man2/fanotify_mark.2
@@ -146,12 +146,102 @@ capability.
 The events in
 .I mask
 shall be added to or removed from the ignore mask.
+Note that the flags
+.B FAN_ONDIR ,
+and
+.B FAN_EVENT_ON_CHILD
+have no effect in combination with this flag.
+The effect of setting those flags in the mask
+on ignoring events that are set in the ignore mask
+is undefined and depend on the Linux kernel version.
+Specifically, prior to Linux 5.9,
+.\" commit 497b0c5a7c0688c1b100a9c2e267337f677c198e
+setting a mark mask on a file
+and a mark with ignore mask on its parent directory
+would not result in ignoring events on the file,
+regardless of the
+.B FAN_EVENT_ON_CHILD
+flag in the parent directory's mark mask.
+When the ignore mask is updated with the
+.B FAN_MARK_IGNORED_MASK
+flag,
+on a mark that was previously updated with the
+.B FAN_MARK_IGNORE
+flag,
+the update fails with
+.B EEXIST
+error.
+.TP
+.BR FAN_MARK_IGNORE " (since Linux 6.0)"
+.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
+This flag has a similar effect as setting the
+.B FAN_MARK_IGNORED_MASK
+flag.
+The events in
+.I mask
+shall be added to or removed from the ignore mask.
+Unlike the
+.B FAN_MARK_IGNORED_MASK
+flag,
+this flag also has the effect that the
+.B FAN_ONDIR ,
+and
+.B FAN_EVENT_ON_CHILD
+flags take effect on the ignore mask.
+Specifically, unless
+.B FAN_ONDIR
+flag is set with
+.BR FAN_MARK_IGNORE ,
+events on directories will not be ignored
+and if the flag
+.B FAN_EVENT_ON_CHILD
+is set,
+events on children will be ignored.
+For example,
+a mark on a directory with combination of
+a mask with
+.B FAN_CREATE
+event
+and
+.B FAN_ONDIR
+flag
+and an ignore mask with
+.B FAN_CREATE
+event
+and without
+.B FAN_ONDIR
+flag,
+will result in getting only events for creation of sub-directories.
+When using this flag to add to an ignore mask
+of a mount, filesystem, or directory inode mark,
+the
+.B FAN_MARK_IGNORED_SURV_MODIFY
+flag must be specified.
+Failure to do so will results with
+.B EINVAL
+or
+.B EISDIR
+error.
 .TP
 .B FAN_MARK_IGNORED_SURV_MODIFY
 The ignore mask shall survive modify events.
 If this flag is not set,
 the ignore mask is cleared when a modify event occurs
 for the ignored file or directory.
+This flag cannot be removed from a mark once set.
+When the ignore mask is updated without this flag,
+on a mark that was previously updated with the
+.B FAN_MARK_IGNORE
+and
+.B FAN_MARK_IGNORED_SURV_MODIFY
+flags,
+the update fails with
+.B EEXIST
+error.
+.TP
+.B FAN_MARK_IGNORE_SURV
+This is a synonym for
+.RB ( FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY ).
 .PP
 .TP
 .BR FAN_MARK_EVICTABLE " (since Linux 5.19)"
@@ -459,6 +549,32 @@ and the user attempted to update the mark with
 .B FAN_MARK_EVICTABLE
 flag.
 .TP
+.B EEXIST
+The filesystem object indicated by
+.I dirfd
+and
+.I pathname
+has a mark that was updated with the
+.B FAN_MARK_IGNORE
+flag,
+and the user attempted to update the mark with
+.B FAN_MARK_IGNORED_MASK
+flag.
+.TP
+.B EEXIST
+The filesystem object indicated by
+.I dirfd
+and
+.I pathname
+has a mark that was updated with the
+.B FAN_MARK_IGNORE
+and
+.B FAN_MARK_IGNORED_SURV_MODIFY
+flags,
+and the user attempted to update the mark only with
+.B FAN_MARK_IGNORE
+flag.
+.TP
 .B EINVAL
 An invalid value was passed in
 .I flags
@@ -484,8 +600,33 @@ but one or more event types specified in the
 .I mask
 require it.
 .TP
+.B EINVAL
+.I flags
+contains
+.BR FAN_MARK_IGNORE ,
+and either
+.B FAN_MARK_MOUNT
+or
+.BR FAN_MARK_FILESYSTEM ,
+but does not contain
+.BR FAN_MARK_IGNORED_SURV_MODIFY .
+.TP
+.B EISDIR
+.I flags
+contains
+.BR FAN_MARK_IGNORE ,
+and
+.BR FAN_MARK_IGNORED_SURV_MODIFY ,
+and
+.I dirfd
+and
+.I pathname
+specify a directory.
+.TP
 .B ENODEV
 The filesystem object indicated by
+.I dirfd
+and
 .I pathname
 is not associated with a filesystem that supports
 .I fsid
@@ -547,8 +688,12 @@ and
 do not specify a directory.
 .TP
 .B ENOTDIR
-The fanotify group was initialized with flag
+.I flags
+contains
+.BR FAN_MARK_IGNORE ,
+or the fanotify group was initialized with flag
 .BR FAN_REPORT_TARGET_FID ,
+and
 .I mask
 contains directory entry modification events
 (e.g.,
-- 
2.25.1

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Jan Kara]

On Sun 04-09-22 18:51:13, Amir Goldstein wrote:
> A new flavor of FAN_MARK_IGNORED_MASK that helps to resolve the
> ambiguity around the combination of event flags and ignore mask.
> 
> It is also more strict in the events and flags allowed to be
> set in a non-directory inode mark mask and it mandates the use
> of FAN_MARK_IGNORED_SURV_MODIFY flag on filesystem, mount and
> directory inode marks.
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>

<snip>

> +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> +This flag has a similar effect as setting the
> +.B FAN_MARK_IGNORED_MASK
> +flag.
> +The events in
> +.I mask
> +shall be added to or removed from the ignore mask.
> +Unlike the
> +.B FAN_MARK_IGNORED_MASK
> +flag,
> +this flag also has the effect that the
> +.B FAN_ONDIR ,
> +and
> +.B FAN_EVENT_ON_CHILD
> +flags take effect on the ignore mask.
> +Specifically, unless
> +.B FAN_ONDIR
> +flag is set with
> +.BR FAN_MARK_IGNORE ,
> +events on directories will not be ignored
> +and if the flag
> +.B FAN_EVENT_ON_CHILD
> +is set,
> +events on children will be ignored.
> +For example,
> +a mark on a directory with combination of
> +a mask with
> +.B FAN_CREATE
> +event
> +and
> +.B FAN_ONDIR
> +flag
> +and an ignore mask with
> +.B FAN_CREATE
> +event
> +and without
> +.B FAN_ONDIR
> +flag,
> +will result in getting only events for creation of sub-directories.
> +When using this flag to add to an ignore mask
> +of a mount, filesystem, or directory inode mark,
> +the
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flag must be specified.

Perhaps a short rationaly why this flag is required would be good here?

> +Failure to do so will results with
> +.B EINVAL
> +or
> +.B EISDIR
> +error.

<snip>

> +.TP
> +.B EISDIR
> +.I flags
> +contains
> +.BR FAN_MARK_IGNORE ,
> +and
> +.BR FAN_MARK_IGNORED_SURV_MODIFY ,

I think it should rather be "but does not contain
FAN_MARK_IGNORED_SURV_MODIFY", shouldn't it?

> +and
> +.I dirfd
> +and
> +.I pathname
> +specify a directory.

Otherwise the changes look good to me.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Amir Goldstein]

On Tue, Sep 6, 2022 at 12:48 PM Jan Kara <jack@suse.cz> wrote:
>
> On Sun 04-09-22 18:51:13, Amir Goldstein wrote:
> > A new flavor of FAN_MARK_IGNORED_MASK that helps to resolve the
> > ambiguity around the combination of event flags and ignore mask.
> >
> > It is also more strict in the events and flags allowed to be
> > set in a non-directory inode mark mask and it mandates the use
> > of FAN_MARK_IGNORED_SURV_MODIFY flag on filesystem, mount and
> > directory inode marks.
> >
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
>
> <snip>
>
> > +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> > +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> > +This flag has a similar effect as setting the
> > +.B FAN_MARK_IGNORED_MASK
> > +flag.
> > +The events in
> > +.I mask
> > +shall be added to or removed from the ignore mask.
> > +Unlike the
> > +.B FAN_MARK_IGNORED_MASK
> > +flag,
> > +this flag also has the effect that the
> > +.B FAN_ONDIR ,
> > +and
> > +.B FAN_EVENT_ON_CHILD
> > +flags take effect on the ignore mask.
> > +Specifically, unless
> > +.B FAN_ONDIR
> > +flag is set with
> > +.BR FAN_MARK_IGNORE ,
> > +events on directories will not be ignored
> > +and if the flag
> > +.B FAN_EVENT_ON_CHILD
> > +is set,
> > +events on children will be ignored.
> > +For example,
> > +a mark on a directory with combination of
> > +a mask with
> > +.B FAN_CREATE
> > +event
> > +and
> > +.B FAN_ONDIR
> > +flag
> > +and an ignore mask with
> > +.B FAN_CREATE
> > +event
> > +and without
> > +.B FAN_ONDIR
> > +flag,
> > +will result in getting only events for creation of sub-directories.
> > +When using this flag to add to an ignore mask
> > +of a mount, filesystem, or directory inode mark,
> > +the
> > +.B FAN_MARK_IGNORED_SURV_MODIFY
> > +flag must be specified.
>
> Perhaps a short rationaly why this flag is required would be good here?

Here is a bit much IMO.
I will add it to the next section.
How's that?

 .B FAN_MARK_IGNORED_SURV_MODIFY
 The ignore mask shall survive modify events.
 If this flag is not set,
 the ignore mask is cleared when a modify event occurs
-for the ignored file or directory.
+on the marked object.
+Omitting this flag is typically used to suppress events
+(e.g.,
+.BR FAN_OPEN )
+for a specific file,
+until that specific file's content has been modified.
+It is far less useful to suppress events
+on an entire filesystem,
+or mount,
+or on all files inside a directory,
+until some file's content has been modified.
+For this reason,
+the
+.B FAN_MARK_IGNORE
+flag requires the
+.B FAN_MARK_IGNORED_SURV_MODIFY
+flag on a mount,
+filesystem,
+or directory inode mark.
+This flag cannot be removed from a mark once set.
+When the ignore mask is updated without this flag,
+on a mark that was previously updated with the
+.B FAN_MARK_IGNORE
+and
+.B FAN_MARK_IGNORED_SURV_MODIFY
+flags,
+the update fails with
+.B EEXIST
+error.
+.TP
+.B FAN_MARK_IGNORE_SURV
+This is a synonym for
+.RB ( FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY ).
 .TP


>
> > +Failure to do so will results with
> > +.B EINVAL
> > +or
> > +.B EISDIR
> > +error.
>
> <snip>
>
> > +.TP
> > +.B EISDIR
> > +.I flags
> > +contains
> > +.BR FAN_MARK_IGNORE ,
> > +and
> > +.BR FAN_MARK_IGNORED_SURV_MODIFY ,
>
> I think it should rather be "but does not contain
> FAN_MARK_IGNORED_SURV_MODIFY", shouldn't it?
>

Yes. Good catch!

Thanks,
Amir.

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Jan Kara]

On Tue 06-09-22 14:13:31, Amir Goldstein wrote:
> On Tue, Sep 6, 2022 at 12:48 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Sun 04-09-22 18:51:13, Amir Goldstein wrote:
> > > A new flavor of FAN_MARK_IGNORED_MASK that helps to resolve the
> > > ambiguity around the combination of event flags and ignore mask.
> > >
> > > It is also more strict in the events and flags allowed to be
> > > set in a non-directory inode mark mask and it mandates the use
> > > of FAN_MARK_IGNORED_SURV_MODIFY flag on filesystem, mount and
> > > directory inode marks.
> > >
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> >
> > <snip>
> >
> > > +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> > > +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> > > +This flag has a similar effect as setting the
> > > +.B FAN_MARK_IGNORED_MASK
> > > +flag.
> > > +The events in
> > > +.I mask
> > > +shall be added to or removed from the ignore mask.
> > > +Unlike the
> > > +.B FAN_MARK_IGNORED_MASK
> > > +flag,
> > > +this flag also has the effect that the
> > > +.B FAN_ONDIR ,
> > > +and
> > > +.B FAN_EVENT_ON_CHILD
> > > +flags take effect on the ignore mask.
> > > +Specifically, unless
> > > +.B FAN_ONDIR
> > > +flag is set with
> > > +.BR FAN_MARK_IGNORE ,
> > > +events on directories will not be ignored
> > > +and if the flag
> > > +.B FAN_EVENT_ON_CHILD
> > > +is set,
> > > +events on children will be ignored.
> > > +For example,
> > > +a mark on a directory with combination of
> > > +a mask with
> > > +.B FAN_CREATE
> > > +event
> > > +and
> > > +.B FAN_ONDIR
> > > +flag
> > > +and an ignore mask with
> > > +.B FAN_CREATE
> > > +event
> > > +and without
> > > +.B FAN_ONDIR
> > > +flag,
> > > +will result in getting only events for creation of sub-directories.
> > > +When using this flag to add to an ignore mask
> > > +of a mount, filesystem, or directory inode mark,
> > > +the
> > > +.B FAN_MARK_IGNORED_SURV_MODIFY
> > > +flag must be specified.
> >
> > Perhaps a short rationaly why this flag is required would be good here?
> 
> Here is a bit much IMO.
> I will add it to the next section.
> How's that?
> 
>  .B FAN_MARK_IGNORED_SURV_MODIFY
>  The ignore mask shall survive modify events.
>  If this flag is not set,
>  the ignore mask is cleared when a modify event occurs
> -for the ignored file or directory.
> +on the marked object.
> +Omitting this flag is typically used to suppress events
> +(e.g.,
> +.BR FAN_OPEN )
> +for a specific file,
> +until that specific file's content has been modified.
> +It is far less useful to suppress events
> +on an entire filesystem,
> +or mount,
> +or on all files inside a directory,
> +until some file's content has been modified.
> +For this reason,
> +the
> +.B FAN_MARK_IGNORE
> +flag requires the
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flag on a mount,
> +filesystem,
> +or directory inode mark.
> +This flag cannot be removed from a mark once set.
> +When the ignore mask is updated without this flag,
> +on a mark that was previously updated with the
> +.B FAN_MARK_IGNORE
> +and
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flags,
> +the update fails with
> +.B EEXIST
> +error.
> +.TP
> +.B FAN_MARK_IGNORE_SURV
> +This is a synonym for
> +.RB ( FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY ).
>  .TP

Yes, looks good.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Matthew Bobrowski]

Maybe some useful nits.

On Sun, Sep 04, 2022 at 06:51:13PM +0300, Amir Goldstein wrote:
> diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
> index 757ad9159..e9303827c 100644
> --- a/man2/fanotify_mark.2
> +++ b/man2/fanotify_mark.2
> @@ -146,12 +146,102 @@ capability.
>  The events in
>  .I mask
>  shall be added to or removed from the ignore mask.
> +Note that the flags
> +.B FAN_ONDIR ,
> +and
> +.B FAN_EVENT_ON_CHILD
> +have no effect in combination with this flag.
> +The effect of setting those flags in the mask

Is there anything wrong with explicitly specifying the exact flags
you're referring to here? Like, "is it those flags there?", or "is it
those flags over there?". Oh wait, you mean "it is those flags
there?".

I think it's best not describe flag usage and behavior of something
based on spatial proximity.

> +on ignoring events that are set in the ignore mask
> +is undefined and depend on the Linux kernel version.

Reading this sentence made me a little confused at first. Just
checking, what I understood was that the use of FAN_ONDIR or
FAN_EVENT_ON_CHILD when setting the ignore mask via
FAN_MARK_IGNORED_MASK leads to undefined behavior. Is my understanding
correct?

> +Specifically, prior to Linux 5.9,
> +.\" commit 497b0c5a7c0688c1b100a9c2e267337f677c198e
> +setting a mark mask on a file
> +and a mark with ignore mask on its parent directory
> +would not result in ignoring events on the file,
> +regardless of the
> +.B FAN_EVENT_ON_CHILD
> +flag in the parent directory's mark mask.
> +When the ignore mask is updated with the
> +.B FAN_MARK_IGNORED_MASK
> +flag,

I'd just allow this sentence to flow without the use of comma after
flag.

> +on a mark that was previously updated with the
> +.B FAN_MARK_IGNORE
> +flag,
> +the update fails with
> +.B EEXIST
> +error.
> +.TP
> +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> +This flag has a similar effect as setting the
> +.B FAN_MARK_IGNORED_MASK
> +flag.
> +The events in
> +.I mask
> +shall be added to or removed from the ignore mask.
> +Unlike the
> +.B FAN_MARK_IGNORED_MASK
> +flag,
> +this flag also has the effect that the
> +.B FAN_ONDIR ,
> +and
> +.B FAN_EVENT_ON_CHILD
> +flags take effect on the ignore mask.
> +Specifically, unless
			^
			the

> +.B FAN_ONDIR
> +flag is set with
> +.BR FAN_MARK_IGNORE ,
> +events on directories will not be ignored
					    ^
					    .
					    
> +and if the flag

I'd start a new sentence here.

> +.B FAN_EVENT_ON_CHILD
> +is set,
> +events on children will be ignored.
> +For example,
> +a mark on a directory with combination of
> +a mask with
> +.B FAN_CREATE
> +event
> +and
> +.B FAN_ONDIR
> +flag
> +and an ignore mask with
> +.B FAN_CREATE
> +event
> +and without
> +.B FAN_ONDIR
> +flag,
> +will result in getting only events for creation of sub-directories.
  	       	  	       	      	 ^
					 the
					 
> +When using this flag to add to an ignore mask
> +of a mount, filesystem, or directory inode mark,
> +the
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flag must be specified.
> +Failure to do so will results with
> +.B EINVAL
> +or
> +.B EISDIR
> +error.
>  .TP
>  .B FAN_MARK_IGNORED_SURV_MODIFY
>  The ignore mask shall survive modify events.
>  If this flag is not set,
>  the ignore mask is cleared when a modify event occurs
>  for the ignored file or directory.
> +This flag cannot be removed from a mark once set.
> +When the ignore mask is updated without this flag,
						    ^
Don't think the comma is needed here.

> +on a mark that was previously updated with the
> +.B FAN_MARK_IGNORE
> +and
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flags,
> +the update fails with
> +.B EEXIST
> +error.
> +.TP
> +.B FAN_MARK_IGNORE_SURV
> +This is a synonym for
> +.RB ( FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY ).
>  .PP
>  .TP
>  .BR FAN_MARK_EVICTABLE " (since Linux 5.19)"
> @@ -459,6 +549,32 @@ and the user attempted to update the mark with
>  .B FAN_MARK_EVICTABLE
>  flag.
>  .TP
> +.B EEXIST
> +The filesystem object indicated by
> +.I dirfd
> +and
> +.I pathname
> +has a mark that was updated with the
> +.B FAN_MARK_IGNORE
> +flag,
> +and the user attempted to update the mark with
> +.B FAN_MARK_IGNORED_MASK
> +flag.
> +.TP
> +.B EEXIST
> +The filesystem object indicated by
> +.I dirfd
> +and
> +.I pathname
> +has a mark that was updated with the
> +.B FAN_MARK_IGNORE
> +and
> +.B FAN_MARK_IGNORED_SURV_MODIFY
> +flags,
> +and the user attempted to update the mark only with
> +.B FAN_MARK_IGNORE
> +flag.
> +.TP
>  .B EINVAL
>  An invalid value was passed in
>  .I flags
> @@ -484,8 +600,33 @@ but one or more event types specified in the
>  .I mask
>  require it.
>  .TP
> +.B EINVAL
> +.I flags
> +contains
> +.BR FAN_MARK_IGNORE ,
> +and either
> +.B FAN_MARK_MOUNT
> +or
> +.BR FAN_MARK_FILESYSTEM ,
> +but does not contain
> +.BR FAN_MARK_IGNORED_SURV_MODIFY .
> +.TP
> +.B EISDIR
> +.I flags
> +contains
> +.BR FAN_MARK_IGNORE ,
> +and
> +.BR FAN_MARK_IGNORED_SURV_MODIFY ,
> +and
> +.I dirfd
> +and
> +.I pathname
> +specify a directory.
> +.TP
>  .B ENODEV
>  The filesystem object indicated by
> +.I dirfd
> +and
>  .I pathname
>  is not associated with a filesystem that supports
>  .I fsid
> @@ -547,8 +688,12 @@ and
>  do not specify a directory.
>  .TP
>  .B ENOTDIR
> -The fanotify group was initialized with flag
> +.I flags
> +contains
> +.BR FAN_MARK_IGNORE ,
> +or the fanotify group was initialized with flag
>  .BR FAN_REPORT_TARGET_FID ,
> +and
>  .I mask
>  contains directory entry modification events
>
> -- 
> 2.25.1
>

/M

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Amir Goldstein]

On Wed, Sep 7, 2022 at 9:46 AM Matthew Bobrowski <repnop@google.com> wrote:
>
> Maybe some useful nits.

Definitely useful.
Thanks!

>
> On Sun, Sep 04, 2022 at 06:51:13PM +0300, Amir Goldstein wrote:
> > diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
> > index 757ad9159..e9303827c 100644
> > --- a/man2/fanotify_mark.2
> > +++ b/man2/fanotify_mark.2
> > @@ -146,12 +146,102 @@ capability.
> >  The events in
> >  .I mask
> >  shall be added to or removed from the ignore mask.
> > +Note that the flags
> > +.B FAN_ONDIR ,
> > +and
> > +.B FAN_EVENT_ON_CHILD
> > +have no effect in combination with this flag.
> > +The effect of setting those flags in the mask
>
> Is there anything wrong with explicitly specifying the exact flags
> you're referring to here? Like, "is it those flags there?", or "is it
> those flags over there?". Oh wait, you mean "it is those flags
> there?".
>
> I think it's best not describe flag usage and behavior of something
> based on spatial proximity.
>

ok.

> > +on ignoring events that are set in the ignore mask
> > +is undefined and depend on the Linux kernel version.
>
> Reading this sentence made me a little confused at first. Just

Yeh, it's a badly phrased sentence.
I tried to improve it a bit:

 .B FAN_MARK_IGNORED_MASK
 The events in
 .I mask
 shall be added to or removed from the ignore mask.
+Note that the flags
+.B FAN_ONDIR ,
+and
+.B FAN_EVENT_ON_CHILD
+have no effect in combination with this flag.
+The effect of setting the flags
+.B FAN_ONDIR ,
+and
+.B FAN_EVENT_ON_CHILD
+in the mark mask
+on the events that are set in the ignore mask
+is undefined and depends on the Linux kernel version.
+Specifically, prior to Linux 5.9,

I would love to get suggestions for improvement.

> checking, what I understood was that the use of FAN_ONDIR or
> FAN_EVENT_ON_CHILD when setting the ignore mask via
> FAN_MARK_IGNORED_MASK leads to undefined behavior. Is my understanding
> correct?
>

Not exactly.
Setting those flags in the ignore mask has no effect
(as mentioned above).
Setting those flags in the mask has undefined behavior
w.r.t whether the events on a directory or on a child will
be ignored, when said events are in the ignore mask.

See the "Specifically" clause below.

> > +Specifically, prior to Linux 5.9,
> > +.\" commit 497b0c5a7c0688c1b100a9c2e267337f677c198e
> > +setting a mark mask on a file
> > +and a mark with ignore mask on its parent directory
> > +would not result in ignoring events on the file,
> > +regardless of the
> > +.B FAN_EVENT_ON_CHILD
> > +flag in the parent directory's mark mask.
> > +When the ignore mask is updated with the
> > +.B FAN_MARK_IGNORED_MASK
> > +flag,
>
> I'd just allow this sentence to flow without the use of comma after
> flag.

ok.

>
> > +on a mark that was previously updated with the
> > +.B FAN_MARK_IGNORE
> > +flag,
> > +the update fails with
> > +.B EEXIST
> > +error.
> > +.TP
> > +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> > +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> > +This flag has a similar effect as setting the
> > +.B FAN_MARK_IGNORED_MASK
> > +flag.
> > +The events in
> > +.I mask
> > +shall be added to or removed from the ignore mask.
> > +Unlike the
> > +.B FAN_MARK_IGNORED_MASK
> > +flag,
> > +this flag also has the effect that the
> > +.B FAN_ONDIR ,
> > +and
> > +.B FAN_EVENT_ON_CHILD
> > +flags take effect on the ignore mask.
> > +Specifically, unless
>                         ^
>                         the
>

ok.

> > +.B FAN_ONDIR
> > +flag is set with
> > +.BR FAN_MARK_IGNORE ,
> > +events on directories will not be ignored
>                                             ^
>                                             .
>
> > +and if the flag
>
> I'd start a new sentence here.

ok.

>
> > +.B FAN_EVENT_ON_CHILD
> > +is set,
> > +events on children will be ignored.
> > +For example,
> > +a mark on a directory with combination of
> > +a mask with
> > +.B FAN_CREATE
> > +event
> > +and
> > +.B FAN_ONDIR
> > +flag
> > +and an ignore mask with
> > +.B FAN_CREATE
> > +event
> > +and without
> > +.B FAN_ONDIR
> > +flag,
> > +will result in getting only events for creation of sub-directories.
>                                          ^
>                                          the

ok.

>
> > +When using this flag to add to an ignore mask
> > +of a mount, filesystem, or directory inode mark,
> > +the
> > +.B FAN_MARK_IGNORED_SURV_MODIFY
> > +flag must be specified.
> > +Failure to do so will results with
> > +.B EINVAL
> > +or
> > +.B EISDIR
> > +error.
> >  .TP
> >  .B FAN_MARK_IGNORED_SURV_MODIFY
> >  The ignore mask shall survive modify events.
> >  If this flag is not set,
> >  the ignore mask is cleared when a modify event occurs
> >  for the ignored file or directory.
> > +This flag cannot be removed from a mark once set.
> > +When the ignore mask is updated without this flag,
>                                                     ^
> Don't think the comma is needed here.

ok.

FYI, I pushed the fixes to:

https://github.com/amir73il/man-pages/commits/fan_mark_ignore

If you want to review them there and provide your RVB,
because I don't intend to post v2 before v6.0 release.

Thanks,
Amir.

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Matthew Bobrowski]

On Wed, Sep 07, 2022 at 01:55:30PM +0300, Amir Goldstein wrote:
> On Wed, Sep 7, 2022 at 9:46 AM Matthew Bobrowski <repnop@google.com> wrote:
> >
> > Maybe some useful nits.
> 
> Definitely useful.
> Thanks!
> 
> >
> > On Sun, Sep 04, 2022 at 06:51:13PM +0300, Amir Goldstein wrote:
> > > diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
> > > index 757ad9159..e9303827c 100644
> > > --- a/man2/fanotify_mark.2
> > > +++ b/man2/fanotify_mark.2
> > > @@ -146,12 +146,102 @@ capability.
> > >  The events in
> > >  .I mask
> > >  shall be added to or removed from the ignore mask.
> > > +Note that the flags
> > > +.B FAN_ONDIR ,
> > > +and
> > > +.B FAN_EVENT_ON_CHILD
> > > +have no effect in combination with this flag.
> > > +The effect of setting those flags in the mask
> >
> > Is there anything wrong with explicitly specifying the exact flags
> > you're referring to here? Like, "is it those flags there?", or "is it
> > those flags over there?". Oh wait, you mean "it is those flags
> > there?".
> >
> > I think it's best not describe flag usage and behavior of something
> > based on spatial proximity.
> >
> 
> ok.
> 
> > > +on ignoring events that are set in the ignore mask
> > > +is undefined and depend on the Linux kernel version.
> >
> > Reading this sentence made me a little confused at first. Just
> 
> Yeh, it's a badly phrased sentence.
> I tried to improve it a bit:
> 
>  .B FAN_MARK_IGNORED_MASK
>  The events in
>  .I mask
>  shall be added to or removed from the ignore mask.
> +Note that the flags
> +.B FAN_ONDIR ,
> +and
> +.B FAN_EVENT_ON_CHILD
> +have no effect in combination with this flag.
> +The effect of setting the flags
> +.B FAN_ONDIR ,
> +and
> +.B FAN_EVENT_ON_CHILD
> +in the mark mask
> +on the events that are set in the ignore mask
> +is undefined and depends on the Linux kernel version.
> +Specifically, prior to Linux 5.9,
> 
> I would love to get suggestions for improvement.
> 
> > checking, what I understood was that the use of FAN_ONDIR or
> > FAN_EVENT_ON_CHILD when setting the ignore mask via
> > FAN_MARK_IGNORED_MASK leads to undefined behavior. Is my understanding
> > correct?
> >
> 
> Not exactly.
> Setting those flags in the ignore mask has no effect
> (as mentioned above).
> Setting those flags in the mask has undefined behavior
> w.r.t whether the events on a directory or on a child will
> be ignored, when said events are in the ignore mask.
> 
> See the "Specifically" clause below.
> 
> > > +Specifically, prior to Linux 5.9,
> > > +.\" commit 497b0c5a7c0688c1b100a9c2e267337f677c198e
> > > +setting a mark mask on a file
> > > +and a mark with ignore mask on its parent directory
> > > +would not result in ignoring events on the file,
> > > +regardless of the
> > > +.B FAN_EVENT_ON_CHILD
> > > +flag in the parent directory's mark mask.
> > > +When the ignore mask is updated with the
> > > +.B FAN_MARK_IGNORED_MASK
> > > +flag,
> >
> > I'd just allow this sentence to flow without the use of comma after
> > flag.
> 
> ok.
> 
> >
> > > +on a mark that was previously updated with the
> > > +.B FAN_MARK_IGNORE
> > > +flag,
> > > +the update fails with
> > > +.B EEXIST
> > > +error.
> > > +.TP
> > > +.BR FAN_MARK_IGNORE " (since Linux 6.0)"
> > > +.\" commit e252f2ed1c8c6c3884ab5dd34e003ed21f1fe6e0
> > > +This flag has a similar effect as setting the
> > > +.B FAN_MARK_IGNORED_MASK
> > > +flag.
> > > +The events in
> > > +.I mask
> > > +shall be added to or removed from the ignore mask.
> > > +Unlike the
> > > +.B FAN_MARK_IGNORED_MASK
> > > +flag,
> > > +this flag also has the effect that the
> > > +.B FAN_ONDIR ,
> > > +and
> > > +.B FAN_EVENT_ON_CHILD
> > > +flags take effect on the ignore mask.
> > > +Specifically, unless
> >                         ^
> >                         the
> >
> 
> ok.
> 
> > > +.B FAN_ONDIR
> > > +flag is set with
> > > +.BR FAN_MARK_IGNORE ,
> > > +events on directories will not be ignored
> >                                             ^
> >                                             .
> >
> > > +and if the flag
> >
> > I'd start a new sentence here.
> 
> ok.
> 
> >
> > > +.B FAN_EVENT_ON_CHILD
> > > +is set,
> > > +events on children will be ignored.
> > > +For example,
> > > +a mark on a directory with combination of
> > > +a mask with
> > > +.B FAN_CREATE
> > > +event
> > > +and
> > > +.B FAN_ONDIR
> > > +flag
> > > +and an ignore mask with
> > > +.B FAN_CREATE
> > > +event
> > > +and without
> > > +.B FAN_ONDIR
> > > +flag,
> > > +will result in getting only events for creation of sub-directories.
> >                                          ^
> >                                          the
> 
> ok.
> 
> >
> > > +When using this flag to add to an ignore mask
> > > +of a mount, filesystem, or directory inode mark,
> > > +the
> > > +.B FAN_MARK_IGNORED_SURV_MODIFY
> > > +flag must be specified.
> > > +Failure to do so will results with
> > > +.B EINVAL
> > > +or
> > > +.B EISDIR
> > > +error.
> > >  .TP
> > >  .B FAN_MARK_IGNORED_SURV_MODIFY
> > >  The ignore mask shall survive modify events.
> > >  If this flag is not set,
> > >  the ignore mask is cleared when a modify event occurs
> > >  for the ignored file or directory.
> > > +This flag cannot be removed from a mark once set.
> > > +When the ignore mask is updated without this flag,
> >                                                     ^
> > Don't think the comma is needed here.
> 
> ok.
> 
> FYI, I pushed the fixes to:
> 
> https://github.com/amir73il/man-pages/commits/fan_mark_ignore

One optional suggestion, but apart from that the refactoring LGTM.

Reviewed-by: Matthew Bobrowski <repnop@google.com>

/M

Re: [RFC][PATCH] fanotify_mark.2: Document FAN_MARK_IGNORE

[Amir Goldstein]

> > FYI, I pushed the fixes to:
> >
> > https://github.com/amir73il/man-pages/commits/fan_mark_ignore
>
> One optional suggestion, but apart from that the refactoring LGTM.
>

Fixed and pushed.

> Reviewed-by: Matthew Bobrowski <repnop@google.com>
>

Unless Alex has any more comments on v1,
I will post the reviewed v2 after v6.0 release.

Thanks!
Amir.