Hi Amir,

On Sun, Mar 30, 2025 at 09:53:36PM +0200, Amir Goldstein wrote:

quoted

I prefer them in two patches.  You can send them in the same patch set,
though.

ok

I pushed the two patches to
https://github.com/amir73il/man-pages/commits/fan_deny_errno

Let me know if you want me to re-post them

Yes, please.

quoted

quoted

This change to the documentation of fanotify permission event response
is independent of the previous patches I posted to document the new
FAN_PRE_ACCESS event (also v6.14) and the fanotify_init(2) flag
FAN_REPORT_FD_ERROR (v6.13).

There is another fanotify feature in v6.14 (mount events).
I will try to catch up on documenting that one as well.

Thanks,
Amir.

 man/man7/fanotify.7 | 60 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/man/man7/fanotify.7 b/man/man7/fanotify.7
index 6f3a9496e..c7b53901a 100644
--- a/man/man7/fanotify.7
+++ b/man/man7/fanotify.7

@@ -820,7 +820,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

This seems unrelated.  Please keep it out of the patches.  If you want
to do it, please have a third trivial patch with "wfix" in the subject.

what does wfix stand for?

wording fix

$ cat CONTRIBUTING.d/patches/subject | sed -n '/Trivial subject/,+12p';
    Trivial subject
	For trivial patches, you can use subject tags:

		ffix	Formatting fix.
		tfix	Typo fix.
		wfix	Minor wording fix.
		srcfix	Change to manual page source that doesn't affect
			the output.

	Example:

		[PATCH v1] tcp.7: tfix

this is not a typo fix, this is a semantic fix.

It is not true that the value of response is either FAN_ALLOW or FAN_DENY
those are flags in a bitset and the correct statement is that exactly
one of them needs to be set.

I understand now.  Then, I think it's more important to have this in a
separate patch, to make sure we document the fix in a commit message.

quoted

quoted

+macro:
+.BR EPERM ,
+.BR EIO ,
+.BR EBUSY ,
+.BR ETXTBSY ,
+.BR EAGAIN ,
+.BR ENOSPC ,
+.BR EDQUOT .

Should we have a manual page for FAN_DENY_ERRNO()?  (I think we should.)
I don't understand how it's supposed to work from this paragraph.

#define FAN_DENY_ERRNO(err) (FAN_DENY | (((err) & 0xff) << 24))

combined FAN_DENY with a specific error, but I see no
reason to expose the internals of this macro

Ahhh, thanks.

This does not deserve a man page of its own IMO.

If you have a suggested for better formatting, please suggest it

How about an example of using it?  I think that'd be more useful than a
lot of text.

quoted

quoted

+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

I'd say '.type' instead of 'type'.  I know there's no consistency about
it, but I'm going to globally fix that eventually.  Let's do it good for
new documentation.  The '.' allows one to easily know that we're talking
about a struct or union member.

Sounds like a good change to me.

pushed requested fixes to github.

Have a lovely night!
Alex

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