[PATCH v2 1/3] fanotify.7: wfix

[PATCH v2 1/3] fanotify.7: wfix

[Amir Goldstein]

Since the introduction of the FAN_AUDIT response flag,
the response field of fanotify_response is no longer an enum
it is now a bitmask, so fix the wording around FAN_ALLOW and
FAN_DENY.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 man/man7/fanotify.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
index a5ddf1df0..ad864b762 100644
--- a/man/man7/fanotify.7
+++ b/man/man7/fanotify.7
@@ -769,7 +769,7 @@ This is the file descriptor from the structure
 .TP
 .I response
 This field indicates whether or not the permission is to be granted.
-Its value must be either
+Its value must contain either the flag
 .B FAN_ALLOW
 to allow the file operation or
 .B FAN_DENY
-- 
2.34.1

[PATCH v2 2/3] fanotify.7: Document FAN_RESPONSE_INFO_AUDIT_RULE

[Amir Goldstein]

Document FAN_RESPONSE_INFO_AUDIT_RULE extended response info record
that was added in v6.3.

Cc: Jan Kara <jack@suse.cz>
Cc: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 man/man7/fanotify.7 | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
index ad864b762..863578bd7 100644
--- a/man/man7/fanotify.7
+++ b/man/man7/fanotify.7
@@ -787,6 +787,49 @@ flag can be set in the
 field.
 In that case, the audit subsystem will log information about the access
 decision to the audit logs.
+.P
+Since Linux 6.3,
+.\" commit 70529a199574c15a40f46b14256633b02ba10ca2
+the
+.B FAN_INFO
+flag can be set in the
+.I .response
+field.
+It indicates that an extra variable-length response record follows the
+.I fanotify_response
+structure.
+Extra response records start with a common header:
+.P
+.in +4n
+.EX
+struct fanotify_response_info_header {
+    __u8 type;
+    __u8 pad;
+    __u16 len;
+};
+.EE
+.in
+.P
+The value of
+.I .type
+determines the format of the extra response record.
+In case the value of
+.I .type
+is
+.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
+the following response record is expected
+with extra details for the audit log:
+.P
+.in +4n
+.EX
+struct fanotify_response_info_audit_rule {
+    struct fanotify_response_info_header hdr;
+    __u32 rule_number;
+    __u32 subj_trust;
+    __u32 obj_trust;
+};
+.EE
+.in
 .\"
 .SS Monitoring filesystems for errors
 A single
-- 
2.34.1

[PATCH v2 3/3] fanotify.7: Document FAN_DENY_ERRNO()

[Amir Goldstein]

Document FAN_DENY_ERRNO(), that was added in v6.13 to
report specific errors on file access.

Cc: Jan Kara <jack@suse.cz>
Cc: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---

Changes since v1:
- Split out to 3 patches
- Add example of FAN_DENY_ERRNO

 man/man7/fanotify.7 | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
index 863578bd7..a532a963a 100644
--- a/man/man7/fanotify.7
+++ b/man/man7/fanotify.7
@@ -778,6 +778,28 @@ to deny the file operation.
 If access is denied, the requesting application call will receive an
 .B EPERM
 error.
+Since Linux 6.13,
+.\" commit b4b2ff4f61ded819bfa22e50fdec7693f51cbbee
+if a notification group is initialized with class
+.BR FAN_CLASS_PRE_CONTENT ,
+the file operation can be denied with errors other than
+.BR EPERM .
+For example, for the requesting application to get the
+.B EIO
+error, the event listener can write the response
+.BR FAN_DENY_ERRNO ( EIO ).
+At the time of writing,
+only the following error values could be returned to the application with
+.BR FAN_DENY_ERRNO
+macro:
+.BR EPERM ,
+.BR EIO ,
+.BR EBUSY ,
+.BR ETXTBSY ,
+.BR EAGAIN ,
+.BR ENOSPC ,
+.BR EDQUOT .
+.P
 Additionally, if the notification group has been created with the
 .B FAN_ENABLE_AUDIT
 flag, then the
-- 
2.34.1

Re: [PATCH v2 1/3] fanotify.7: wfix

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Hi Amir,

On Mon, Mar 31, 2025 at 10:27:57AM +0200, Amir Goldstein wrote:
> Since the introduction of the FAN_AUDIT response flag,
> the response field of fanotify_response is no longer an enum
> it is now a bitmask, so fix the wording around FAN_ALLOW and
> FAN_DENY.
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>

Thanks!  I've applied the patch.  BTW, I've reworded the subject:

	man/man7/fanotify.7: The response field is now a bit mask instead of an enum


Cheers,
Alex

> ---
>  man/man7/fanotify.7 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
> index a5ddf1df0..ad864b762 100644
> --- a/man/man7/fanotify.7
> +++ b/man/man7/fanotify.7
> @@ -769,7 +769,7 @@ This is the file descriptor from the structure
>  .TP
>  .I response
>  This field indicates whether or not the permission is to be granted.
> -Its value must be either
> +Its value must contain either the flag
>  .B FAN_ALLOW
>  to allow the file operation or
>  .B FAN_DENY
> -- 
> 2.34.1
> 

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/3] fanotify.7: Document FAN_RESPONSE_INFO_AUDIT_RULE

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3779 bytes --]

Hi Amir,

On Mon, Mar 31, 2025 at 10:27:58AM +0200, Amir Goldstein wrote:
> Document FAN_RESPONSE_INFO_AUDIT_RULE extended response info record
> that was added in v6.3.
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Richard Guy Briggs <rgb@redhat.com>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  man/man7/fanotify.7 | 43 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
> index ad864b762..863578bd7 100644
> --- a/man/man7/fanotify.7
> +++ b/man/man7/fanotify.7
> @@ -787,6 +787,49 @@ flag can be set in the
>  field.
>  In that case, the audit subsystem will log information about the access
>  decision to the audit logs.
> +.P
> +Since Linux 6.3,
> +.\" commit 70529a199574c15a40f46b14256633b02ba10ca2
> +the
> +.B FAN_INFO
> +flag can be set in the
> +.I .response
> +field.
> +It indicates that an extra variable-length response record follows the
> +.I fanotify_response
> +structure.
> +Extra response records start with a common header:
> +.P
> +.in +4n
> +.EX
> +struct fanotify_response_info_header {
> +    __u8 type;
> +    __u8 pad;
> +    __u16 len;
> +};
> +.EE
> +.in
> +.P
> +The value of
> +.I .type
> +determines the format of the extra response record.
> +In case the value of
> +.I .type
> +is
> +.BR FAN_RESPONSE_INFO_AUDIT_RULE ,

How about making this more schematic?  I'm thinking of the following
(see diff for both the source code and the rendered page).


Cheers,
Alex

$ git diff
diff --git i/man/man7/fanotify.7 w/man/man7/fanotify.7
index 863578bd7..4b1e2c215 100644
--- i/man/man7/fanotify.7
+++ w/man/man7/fanotify.7
@@ -813,13 +813,11 @@ .SS Dealing with permission events
 The value of
 .I .type
 determines the format of the extra response record.
-In case the value of
-.I .type
-is
-.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
-the following response record is expected
+.TP
+.BR FAN_RESPONSE_INFO_AUDIT_RULE
+The following response record is expected
 with extra details for the audit log:
-.P
+.IP
 .in +4n
 .EX
 struct fanotify_response_info_audit_rule {
$ MANWIDTH=72 diffman-git 
--- HEAD:man/man7/fanotify.7
+++ ./man/man7/fanotify.7
@@ -539,16 +539,18 @@
          };
 
      The value of .type determines the format  of  the  extra  response
-     record.   In  case  the  value  of  .type is FAN_RESPONSE_INFO_AU‐
-     DIT_RULE, the following response record is expected with extra de‐
-     tails for the audit log:
+     record.
 
-         struct fanotify_response_info_audit_rule {
-             struct fanotify_response_info_header hdr;
-             __u32 rule_number;
-             __u32 subj_trust;
-             __u32 obj_trust;
-         };
+     FAN_RESPONSE_INFO_AUDIT_RULE
+            The  following  response  record is expected with extra de‐
+            tails for the audit log:
+
+                struct fanotify_response_info_audit_rule {
+                    struct fanotify_response_info_header hdr;
+                    __u32 rule_number;
+                    __u32 subj_trust;
+                    __u32 obj_trust;
+                };
 
    Monitoring filesystems for errors
      A single FAN_FS_ERROR event is stored per filesystem at once.  Ex‐


> +the following response record is expected
> +with extra details for the audit log:
> +.P
> +.in +4n
> +.EX
> +struct fanotify_response_info_audit_rule {
> +    struct fanotify_response_info_header hdr;
> +    __u32 rule_number;
> +    __u32 subj_trust;
> +    __u32 obj_trust;
> +};
> +.EE
> +.in
>  .\"
>  .SS Monitoring filesystems for errors
>  A single
> -- 
> 2.34.1
> 

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] fanotify.7: Document FAN_DENY_ERRNO()

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Hi Amir,

On Mon, Mar 31, 2025 at 10:27:59AM +0200, Amir Goldstein wrote:
> Document FAN_DENY_ERRNO(), that was added in v6.13 to
> report specific errors on file access.
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---

Thanks!  I've applied the patch.


Cheers,
Alex

> 
> Changes since v1:
> - Split out to 3 patches
> - Add example of FAN_DENY_ERRNO
> 
>  man/man7/fanotify.7 | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
> index 863578bd7..a532a963a 100644
> --- a/man/man7/fanotify.7
> +++ b/man/man7/fanotify.7
> @@ -778,6 +778,28 @@ to deny the file operation.
>  If access is denied, the requesting application call will receive an
>  .B EPERM
>  error.
> +Since Linux 6.13,
> +.\" commit b4b2ff4f61ded819bfa22e50fdec7693f51cbbee
> +if a notification group is initialized with class
> +.BR FAN_CLASS_PRE_CONTENT ,
> +the file operation can be denied with errors other than
> +.BR EPERM .
> +For example, for the requesting application to get the
> +.B EIO
> +error, the event listener can write the response
> +.BR FAN_DENY_ERRNO ( EIO ).
> +At the time of writing,
> +only the following error values could be returned to the application with
> +.BR FAN_DENY_ERRNO
> +macro:
> +.BR EPERM ,
> +.BR EIO ,
> +.BR EBUSY ,
> +.BR ETXTBSY ,
> +.BR EAGAIN ,
> +.BR ENOSPC ,
> +.BR EDQUOT .
> +.P
>  Additionally, if the notification group has been created with the
>  .B FAN_ENABLE_AUDIT
>  flag, then the
> -- 
> 2.34.1
> 

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/3] fanotify.7: Document FAN_RESPONSE_INFO_AUDIT_RULE

[Amir Goldstein]

On Mon, Mar 31, 2025 at 11:01 AM Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Amir,
>
> On Mon, Mar 31, 2025 at 10:27:58AM +0200, Amir Goldstein wrote:
> > Document FAN_RESPONSE_INFO_AUDIT_RULE extended response info record
> > that was added in v6.3.
> >
> > Cc: Jan Kara <jack@suse.cz>
> > Cc: Richard Guy Briggs <rgb@redhat.com>
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> >  man/man7/fanotify.7 | 43 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
> > index ad864b762..863578bd7 100644
> > --- a/man/man7/fanotify.7
> > +++ b/man/man7/fanotify.7
> > @@ -787,6 +787,49 @@ flag can be set in the
> >  field.
> >  In that case, the audit subsystem will log information about the access
> >  decision to the audit logs.
> > +.P
> > +Since Linux 6.3,
> > +.\" commit 70529a199574c15a40f46b14256633b02ba10ca2
> > +the
> > +.B FAN_INFO
> > +flag can be set in the
> > +.I .response
> > +field.
> > +It indicates that an extra variable-length response record follows the
> > +.I fanotify_response
> > +structure.
> > +Extra response records start with a common header:
> > +.P
> > +.in +4n
> > +.EX
> > +struct fanotify_response_info_header {
> > +    __u8 type;
> > +    __u8 pad;
> > +    __u16 len;
> > +};
> > +.EE
> > +.in
> > +.P
> > +The value of
> > +.I .type
> > +determines the format of the extra response record.
> > +In case the value of
> > +.I .type
> > +is
> > +.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
>
> How about making this more schematic?  I'm thinking of the following
> (see diff for both the source code and the rendered page).
>
>
> Cheers,
> Alex
>
> $ git diff
> diff --git i/man/man7/fanotify.7 w/man/man7/fanotify.7
> index 863578bd7..4b1e2c215 100644
> --- i/man/man7/fanotify.7
> +++ w/man/man7/fanotify.7
> @@ -813,13 +813,11 @@ .SS Dealing with permission events
>  The value of
>  .I .type
>  determines the format of the extra response record.
> -In case the value of
> -.I .type
> -is
> -.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
> -the following response record is expected
> +.TP
> +.BR FAN_RESPONSE_INFO_AUDIT_RULE
> +The following response record is expected
>  with extra details for the audit log:
> -.P
> +.IP
>  .in +4n
>  .EX
>  struct fanotify_response_info_audit_rule {
> $ MANWIDTH=72 diffman-git
> --- HEAD:man/man7/fanotify.7
> +++ ./man/man7/fanotify.7
> @@ -539,16 +539,18 @@
>           };
>
>       The value of .type determines the format  of  the  extra  response
> -     record.   In  case  the  value  of  .type is FAN_RESPONSE_INFO_AU‐
> -     DIT_RULE, the following response record is expected with extra de‐
> -     tails for the audit log:
> +     record.
>
> -         struct fanotify_response_info_audit_rule {
> -             struct fanotify_response_info_header hdr;
> -             __u32 rule_number;
> -             __u32 subj_trust;
> -             __u32 obj_trust;
> -         };
> +     FAN_RESPONSE_INFO_AUDIT_RULE
> +            The  following  response  record is expected with extra de‐
> +            tails for the audit log:
> +
> +                struct fanotify_response_info_audit_rule {
> +                    struct fanotify_response_info_header hdr;
> +                    __u32 rule_number;
> +                    __u32 subj_trust;
> +                    __u32 obj_trust;
> +                };
>
>     Monitoring filesystems for errors
>       A single FAN_FS_ERROR event is stored per filesystem at once.  Ex‐
>

I think this is nicer.
Feel free to apply your version.

While at it, you may want to consider a similar reformatting
to the section describing the extra information records in events
starting with:

"Information  records  are supplemental pieces of information..."

and then with:

"Information records that are supplied alongside..."

I know making an order in this would be too much for me...

Thanks,
Amir.

Re: [PATCH v2 2/3] fanotify.7: Document FAN_RESPONSE_INFO_AUDIT_RULE

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

Hi Amir,

On Mon, Mar 31, 2025 at 11:46:33AM +0200, Amir Goldstein wrote:
> > How about making this more schematic?  I'm thinking of the following
> > (see diff for both the source code and the rendered page).
> >
> >
> > Cheers,
> > Alex
> >
> > $ git diff
> > diff --git i/man/man7/fanotify.7 w/man/man7/fanotify.7
> > index 863578bd7..4b1e2c215 100644
> > --- i/man/man7/fanotify.7
> > +++ w/man/man7/fanotify.7
> > @@ -813,13 +813,11 @@ .SS Dealing with permission events
> >  The value of
> >  .I .type
> >  determines the format of the extra response record.
> > -In case the value of
> > -.I .type
> > -is
> > -.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
> > -the following response record is expected
> > +.TP
> > +.BR FAN_RESPONSE_INFO_AUDIT_RULE
> > +The following response record is expected
> >  with extra details for the audit log:
> > -.P
> > +.IP
> >  .in +4n
> >  .EX
> >  struct fanotify_response_info_audit_rule {
> > $ MANWIDTH=72 diffman-git
> > --- HEAD:man/man7/fanotify.7
> > +++ ./man/man7/fanotify.7
> > @@ -539,16 +539,18 @@
> >           };
> >
> >       The value of .type determines the format  of  the  extra  response
> > -     record.   In  case  the  value  of  .type is FAN_RESPONSE_INFO_AU‐
> > -     DIT_RULE, the following response record is expected with extra de‐
> > -     tails for the audit log:
> > +     record.
> >
> > -         struct fanotify_response_info_audit_rule {
> > -             struct fanotify_response_info_header hdr;
> > -             __u32 rule_number;
> > -             __u32 subj_trust;
> > -             __u32 obj_trust;
> > -         };
> > +     FAN_RESPONSE_INFO_AUDIT_RULE
> > +            The  following  response  record is expected with extra de‐
> > +            tails for the audit log:
> > +
> > +                struct fanotify_response_info_audit_rule {
> > +                    struct fanotify_response_info_header hdr;
> > +                    __u32 rule_number;
> > +                    __u32 subj_trust;
> > +                    __u32 obj_trust;
> > +                };
> >
> >     Monitoring filesystems for errors
> >       A single FAN_FS_ERROR event is stored per filesystem at once.  Ex‐
> >
> 
> I think this is nicer.
> Feel free to apply your version.
> 
> While at it, you may want to consider a similar reformatting
> to the section describing the extra information records in events
> starting with:
> 
> "Information  records  are supplemental pieces of information..."
> 
> and then with:
> 
> "Information records that are supplied alongside..."

Thanks!  I will.


Cheers,
Alex

> 
> I know making an order in this would be too much for me...
> 
> Thanks,
> Amir.

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/3] fanotify.7: Document FAN_RESPONSE_INFO_AUDIT_RULE

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 4604 bytes --]

Hi Amir,

On Mon, Mar 31, 2025 at 11:46:33AM +0200, Amir Goldstein wrote:
> On Mon, Mar 31, 2025 at 11:01 AM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > Hi Amir,
> >
> > On Mon, Mar 31, 2025 at 10:27:58AM +0200, Amir Goldstein wrote:
> > > Document FAN_RESPONSE_INFO_AUDIT_RULE extended response info record
> > > that was added in v6.3.
> > >
> > > Cc: Jan Kara <jack@suse.cz>
> > > Cc: Richard Guy Briggs <rgb@redhat.com>
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > ---
> > >  man/man7/fanotify.7 | 43 +++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >
> > > diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
> > > index ad864b762..863578bd7 100644
> > > --- a/man/man7/fanotify.7
> > > +++ b/man/man7/fanotify.7
> > > @@ -787,6 +787,49 @@ flag can be set in the
> > >  field.
> > >  In that case, the audit subsystem will log information about the access
> > >  decision to the audit logs.
> > > +.P
> > > +Since Linux 6.3,
> > > +.\" commit 70529a199574c15a40f46b14256633b02ba10ca2
> > > +the
> > > +.B FAN_INFO
> > > +flag can be set in the
> > > +.I .response
> > > +field.
> > > +It indicates that an extra variable-length response record follows the
> > > +.I fanotify_response
> > > +structure.
> > > +Extra response records start with a common header:
> > > +.P
> > > +.in +4n
> > > +.EX
> > > +struct fanotify_response_info_header {
> > > +    __u8 type;
> > > +    __u8 pad;
> > > +    __u16 len;
> > > +};
> > > +.EE
> > > +.in
> > > +.P
> > > +The value of
> > > +.I .type
> > > +determines the format of the extra response record.
> > > +In case the value of
> > > +.I .type
> > > +is
> > > +.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
> >
> > How about making this more schematic?  I'm thinking of the following
> > (see diff for both the source code and the rendered page).
> >
> >
> > Cheers,
> > Alex
> >
> > $ git diff
> > diff --git i/man/man7/fanotify.7 w/man/man7/fanotify.7
> > index 863578bd7..4b1e2c215 100644
> > --- i/man/man7/fanotify.7
> > +++ w/man/man7/fanotify.7
> > @@ -813,13 +813,11 @@ .SS Dealing with permission events
> >  The value of
> >  .I .type
> >  determines the format of the extra response record.
> > -In case the value of
> > -.I .type
> > -is
> > -.BR FAN_RESPONSE_INFO_AUDIT_RULE ,
> > -the following response record is expected
> > +.TP
> > +.BR FAN_RESPONSE_INFO_AUDIT_RULE
> > +The following response record is expected
> >  with extra details for the audit log:
> > -.P
> > +.IP
> >  .in +4n
> >  .EX
> >  struct fanotify_response_info_audit_rule {
> > $ MANWIDTH=72 diffman-git
> > --- HEAD:man/man7/fanotify.7
> > +++ ./man/man7/fanotify.7
> > @@ -539,16 +539,18 @@
> >           };
> >
> >       The value of .type determines the format  of  the  extra  response
> > -     record.   In  case  the  value  of  .type is FAN_RESPONSE_INFO_AU‐
> > -     DIT_RULE, the following response record is expected with extra de‐
> > -     tails for the audit log:
> > +     record.
> >
> > -         struct fanotify_response_info_audit_rule {
> > -             struct fanotify_response_info_header hdr;
> > -             __u32 rule_number;
> > -             __u32 subj_trust;
> > -             __u32 obj_trust;
> > -         };
> > +     FAN_RESPONSE_INFO_AUDIT_RULE
> > +            The  following  response  record is expected with extra de‐
> > +            tails for the audit log:
> > +
> > +                struct fanotify_response_info_audit_rule {
> > +                    struct fanotify_response_info_header hdr;
> > +                    __u32 rule_number;
> > +                    __u32 subj_trust;
> > +                    __u32 obj_trust;
> > +                };
> >
> >     Monitoring filesystems for errors
> >       A single FAN_FS_ERROR event is stored per filesystem at once.  Ex‐
> >
> 
> I think this is nicer.
> Feel free to apply your version.

I have applied your patch amended with my diff.


Cheers,
Alex

> 
> While at it, you may want to consider a similar reformatting
> to the section describing the extra information records in events
> starting with:
> 
> "Information  records  are supplemental pieces of information..."
> 
> and then with:
> 
> "Information records that are supplied alongside..."
> 
> I know making an order in this would be too much for me...
> 
> Thanks,
> Amir.

-- 
<https://www.alejandro-colomar.es/>
<https://www.alejandro-colomar.es:8443/>
<http://www.alejandro-colomar.es:8080/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]