From: Alejandro Colomar <alx@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH man-pages] man/man2const: document the new F_SETDELEG and F_GETDELEG constants
Date: Tue, 13 Jan 2026 16:12:04 +0100 [thread overview]
Message-ID: <aWZecUT7o_cYH5Rt@devuan> (raw)
In-Reply-To: <14e88ee6ff3ffd671f579d103c53ebe98b4f92e2.camel@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 14452 bytes --]
Hi Jeff,
On Tue, Jan 13, 2026 at 09:45:11AM -0500, Jeff Layton wrote:
[...]
> > > +.SH SYNOPSIS
> > > +.nf
> > > +.B #define _GNU_SOURCE
> > > +.B #include <fcntl.h>
> > > +.P
> > > +.EX
> > > +/* Argument structure for F_GETDELEG and F_SETDELEG */
> >
> > I'd say this comment seems redundant, given this structure is defined
> > in this manual page.
> >
>
> Ack. Will remove.
>
> > > +struct delegation {
> > > + __u32 d_flags;
> > > + __u16 d_type;
> > > + __u16 __pad;
> > > +};
> > > +.EE
> > > +.P
> > > +.BI "int fcntl(int " fd ", F_SETDELEG, struct delegation *" deleg );
> >
> > Is this really not const-qualified? Does the kernel modify it?
> >
>
> Yes, it does modify it. F_GETDELEG populates d_type. I have some plans
> to expand this interface in the future so F_GETDELEG may eventually
> return other fields in there too.
But I mean F_SETDELEG (with an S). I expect the setter wouldn't modify,
right?
>
> > > +.br
> >
> > This .br seems superfluous.
> >
>
> You would think, no? But when I remove it, man seems to stick both
> lines togther. I really do not grok groff at all.
>
> I'm happy to accept other suggestions on how to fix that though.
Ahhh, sorry! I see why. So, we have EX/EE nested within nf/fi. These
don't nest correctly, so one should close nf/fi, then do EX/EE, and then
open a new nf/fi pair.
> > > +.BI "int fcntl(int " fd ", F_GETDELEG, struct delegation *" deleg );
> > > +.fi
> > > +.SH DESCRIPTION
> > > +.SS Delegations
> >
> > If the entire section is within a subsection, I think the subsection is
> > redundant, isn't it?
> >
>
> Oh ok, I cargo-cult copied most of this from F_GETLEASE.man2const, so
> this may be there as well.
I was supposing you had done that, but didn't figure out from which. :)
Now it makes sense. Yes, I should remove that from
F_GETLEASE.man2const. It is a left-over from when I split the page
from fcntl(2).
> > > +.B F_SETDELEG
> > > +and
> > > +.B F_GETDELEG
> > > +are used to establish a new delegation,
> > > +and retrieve the current delegation, on the open file description
> > > +referred to by the file descriptor
> >
> > Just to confirm: one can't retrieve delegations through a different file
> > description that refers to the same inode, right?
> >
>
> Correct. F_GETDELEG just fills out ->d_type with the type of delegation
> set on "fd".
Thanks!
> > > +.IR fd .
> >
> > I'd separate the paragraph here. The above serves as a brief
> > introduction of these two APIs, while the following text describes what
> > delegations are.
> >
>
> Ok.
>
> > > +A file delegation is a mechanism whereby the process holding
> > > +the delegation (the "delegation holder") is notified (via delivery of a signal)
> > > +when a process (the "delegation breaker") tries to
> > > +.BR open (2)
> > > +or
> > > +.BR truncate (2)
> > > +the file referred to by that file descriptor, or attempts to
> > > +.BR unlink (2)
> > > +or
> > > +.BR rename (2)
> > > +the dentry that was originally opened for the file.
> > > +.BR F_RDLCK
> > > +delegations can also be set on directory file descriptors, in which case they will
> > > +be recalled if there is a create, delete or rename of a dirent within the directory.
> >
> > Please use semantic newlines. See man-pages(7):
> >
> > $ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
> > Use semantic newlines
> > In the source of a manual page, new sentences should be started on
> > new lines, long sentences should be split into lines at clause
> > breaks (commas, semicolons, colons, and so on), and long clauses
> > should be split at phrase boundaries. This convention, sometimes
> > known as "semantic newlines", makes it easier to see the effect of
> > patches, which often operate at the level of individual sentences,
> > clauses, or phrases.
> >
>
> Ok, I'll reformat that.
This applies also to the rest of the page, BTW.
> > > +.TP
> > > +.B F_SETDELEG
> > > +Set or remove a file or directory delegation according to which of the following
> > > +values is specified in the
> > > +.IR d_type
> >
> > s/IR/I/
> >
> > IR is for alternating Italics and Roman.
> >
> > Also, it would be good to use '.d_type' notation, for making it easier
> > to distinguish struct members. A few manual pages already do this.
> > Thus:
> >
> > .I .d_type
> >
> > > +field of
> > > +.IR deleg :
> >
> > Maybe we could even simplify this as:
> >
> > ...
> > specified in
> > .IR deleg->d_type :
> >
>
> Ok
>
> > > +.RS
> > > +.TP
> > > +.B F_RDLCK
> > > +Take out a read delegation.
> >
> > 'Take out' means to remove, but by reading the context, I think this
> > instead creates a read delegation, right? Would it be correct to say
> > this?:
> >
> > Create a read delegation.
> >
> > (I'm not a native English speaker, so I may be mistaken.)
> >
>
> Delegations are returnable, so "take out" in the sense of a library
> book or some other returnable object. I'll rephrase that, since it's
> unclear.
>
> > > +This will cause the calling process to be notified when
> > > +the file is opened for writing or is truncated, or when the file is unlinked or renamed.
> > > +A read delegation can be placed only on a file descriptor that
> > > +is opened read-only. If
> > > +.IR fd
> > > +refers to a directory, then the calling process
> > > +will be notified if there are changes to filenames within the directory, or when the
> > > +directory itself is renamed.
> > > +.TP
> > > +.B F_WRLCK
> >
> > Are we in time to rename this?
> >
> > F_RDLCK blocks essentially writing.
> > F_WRLCK blocks both reading and writing.
> >
> > What do you think of this rename:
> >
> > RD => WR
> > WR => RW
> >
>
> These are constants from file locking. I suppose we could add new
> constants that overload those values?
Ahhh, so this is already a historical thing. Indeed:
$ grep -rn F_RDLCK man/
man/man2const/F_GETLEASE.2const:45:.B F_RDLCK
man/man2const/F_GETLEASE.2const:89:.BR F_RDLCK ", " F_WRLCK ", or " F_UNLCK ,
man/man2const/F_GETLEASE.2const:123:.BR F_RDLCK .
man/man2const/F_GETLEASE.2const:133:.B F_RDLCK
man/man2/fcntl_locking.2:52: short l_type; /* Type of lock: F_RDLCK,
man/man2/fcntl_locking.2:123:.RB ( F_RDLCK )
man/man2/fcntl_locking.2:143:.B F_RDLCK
man/man2/fcntl_locking.2:360:.B F_RDLCK
I guess that answers my question: no, we can't rename these.
Let's keep the historical names.
> > > +Take out a write delegation.
> > > +This will cause the caller to be notified when
> > > +the file is opened for reading or writing or is truncated or when the file is renamed
> > > +or unlinked. A write delegation may be placed on a file only if there are no
> > > +other open file descriptors for the file. The file must be opened for write in order
> > > +to set a write delegation on it. Write delegations cannot be set on directory
> > > +file descriptors.
> > > +.TP
> > > +.B F_UNLCK
> > > +Remove our delegation from the file.
> > > +.RE
> > > +.P
> > > +Like leases, delegations are associated with an open file description (see
> > > +.BR open (2)).
> > > +This means that duplicate file descriptors (created by, for example,
> > > +.BR fork (2)
> > > +or
> > > +.BR dup (2))
> > > +refer to the same delegation, and this delegation may be modified
> > > +or released using any of these descriptors.
> > > +Furthermore, the delegation is released by either an explicit
> > > +.B F_UNLCK
> > > +operation on any of these duplicate file descriptors, or when all
> > > +such file descriptors have been closed.
> > > +.P
> > > +An unprivileged process may take out a delegation only on a file whose
> > > +UID (owner) matches the filesystem UID of the process.
> > > +A process with the
> > > +.B CAP_LEASE
> > > +capability may take out delegations on arbitrary files or directories.
> > > +.TP
> > > +.B F_GETDELEG
> > > +Indicates what type of delegation is associated with the file descriptor
> > > +.I fd
> > > +by setting the
> > > +.IR d_type
> > > +field in
> > > +.IR deleg
> > > +to either
> > > +.BR F_RDLCK ", " F_WRLCK ", or " F_UNLCK ,
> >
> > Please use a separate line for each:
> >
> > .BR F_RDLCK ,
> > .BR F_WRLCK ,
> > or
> > .BR F_UNLCK ,
> >
> > > +indicating, respectively, a read delegation , a write delegation, or no delegation.
> >
>
> ACK
>
> > Spurious white space before comma.
> >
>
> ACK
>
> > > +.P
> > > +When a process (the "delegation breaker") performs an activity
> > > +that conflicts with a delegation established via
> > > +.BR F_SETDELEG ,
> > > +the system call is blocked by the kernel and
> > > +the kernel notifies the delegation holder by sending it a signal
> > > +.RB ( SIGIO
> > > +by default).
> > > +The delegation holder should respond to receipt of this signal by doing
> > > +whatever cleanup is required in preparation for the file to be
> > > +accessed by another process (e.g., flushing cached buffers) and
> > > +then either remove or downgrade its delegation.
> > > +A delegation is removed by performing an
> > > +.B F_SETDELEG
> > > +operation specifying
> > > +.I d_type
> > > +in
> > > +.I deleg
> > > +as
> > > +.BR F_UNLCK .
> > > +If the delegation holder currently holds a write delegation on the file,
> > > +and the delegation breaker is opening the file for reading,
> > > +then it is sufficient for the delegation holder to downgrade
> > > +the delegation to a read delegation.
> > > +This is done by performing an
> > > +.B F_SETDELEG
> > > +operation specifying
> > > +.I d_type
> > > +in
> > > +.I deleg
> > > +as
> > > +.BR F_RDLCK .
> > > +.P
> > > +If the delegation holder fails to downgrade or remove the delegation within
> > > +the number of seconds specified in
> > > +.IR /proc/sys/fs/lease\-break\-time ,
> > > +then the kernel forcibly removes or downgrades the delegation holder's delegation.
> > > +.P
> > > +Once a delegation break has been initiated,
> > > +.B F_GETDELEG
> > > +returns the target delegation type in the
> > > +.I d_type
> > > +field in
> > > +.I deleg
> > > +(either
> > > +.B F_RDLCK
> > > +or
> > > +.BR F_UNLCK ,
> > > +depending on what would be compatible with the delegation breaker)
> > > +until the delegation holder voluntarily downgrades or removes the delegation or
> > > +the kernel forcibly does so after the delegation break timer expires.
> > > +.P
> > > +Once the delegation has been voluntarily or forcibly removed or downgraded,
> > > +and assuming the delegation breaker has not unblocked its system call,
> > > +the kernel permits the delegation breaker's system call to proceed.
> > > +.P
> > > +If the delegation breaker's blocked system call
> > > +is interrupted by a signal handler,
> > > +then the system call fails with the error
> > > +.BR EINTR ,
> > > +but the other steps still occur as described above.
> > > +If the delegation breaker is killed by a signal while blocked in
> > > +.BR open (2)
> > > +or
> > > +.BR truncate (2),
> > > +then the other steps still occur as described above.
> > > +If the delegation breaker specifies the
> > > +.B O_NONBLOCK
> > > +flag when calling
> > > +.BR open (2),
> > > +then the call immediately fails with the error
> > > +.BR EWOULDBLOCK ,
> > > +but the other steps still occur as described above.
> > > +.P
> > > +The default signal used to notify the delegation holder is
> > > +.BR SIGIO ,
> > > +but this can be changed using the
> > > +.B F_SETSIG
> > > +operation to
> > > +.BR fcntl ().
> > > +If a
> > > +.B F_SETSIG
> > > +operation is performed (even one specifying
> > > +.BR SIGIO ),
> > > +and the signal
> > > +handler is established using
> > > +.BR SA_SIGINFO ,
> > > +then the handler will receive a
> > > +.I siginfo_t
> > > +structure as its second argument, and the
> > > +.I si_fd
> > > +field of this argument will hold the file descriptor of the file with the delegation
> > > +that has been accessed by another process.
> > > +(This is useful if the caller holds delegations against multiple files.)
> > > +.SH NOTES
> > > +Delegations were designed to implement NFSv4 delegations for the Linux NFS server, and
> > > +conform to the delegation semantics described in RFC\ 8881.
> >
> > I'd say the part after the comma is redundant with the STANDARDS
> > section.
> >
>
> Ok.
>
> > > +.SH RETURN VALUE
> > > +On success zero is returned. On error, \-1 is returned, and
> > > +.I errno
> > > +is set to indicate the error. A successful F_GETDELEG call will also update the
> >
> > F_GETDELEG should be in bold.
> >
>
> Ok.
>
> > > +.I d_type
> > > +field in the structure to which
> > > +.I deleg
> > > +points.
> > > +.SH ERRORS
> > > +See
> > > +.BR fcntl (2).
> >
> > I guess there are also errors specific to delegations, right? I expect
> > for example an error if F_SETDELEG is called with F_WRLCK but more file
> > descriptors are open for the same file.
> >
>
> Only if the file descriptor was opened non-blocking. The errors are
> basically the same as the ones for leases. I can transplant the
> relevant error messages here though.
Hmm, I see the F_SETLEASE page doesn't document those either.
I think it would be good to document the errors, and in F_GETLEASE too,
if you can. (Feel free to leave that for a later patch.)
> > > +.SH STANDARDS
> > > +Linux, IETF RFC\ 8881.
> > > +.SH HISTORY
> > > +Linux v6.19.
> >
> > Please remove the 'v'.
> >
>
> ACK.
>
> > > +.SH SEE ALSO
> > > +.BR fcntl (2)
> > > diff --git a/man/man2const/F_SETDELEG.2const b/man/man2const/F_SETDELEG.2const
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..acabdfc139fb3d753dbf3061c31d59332d046c63
> > > --- /dev/null
> > > +++ b/man/man2const/F_SETDELEG.2const
> > > @@ -0,0 +1 @@
> > > +.so man2const/F_GETDELEG.2const
> >
> > Thanks!
> >
> >
> > Have a lovely day!
> > Alex
>
> Thank you for the review! I'll update and send a v2.
Thanks!
Cheers,
Alex
>
> Cheers,
> --
> Jeff Layton <jlayton@kernel.org>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-01-13 15:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 18:47 [PATCH man-pages] man/man2const: document the new F_SETDELEG and F_GETDELEG constants Jeff Layton
2026-01-13 14:13 ` Alejandro Colomar
2026-01-13 14:45 ` Jeff Layton
2026-01-13 15:05 ` G. Branden Robinson
2026-01-13 15:12 ` Alejandro Colomar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWZecUT7o_cYH5Rt@devuan \
--to=alx@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.