polyphony 0.94 → 0.95

data/vendor/liburing/man/io_uring_cq_has_overflow.3

@@ -0,0 +1,25 @@
+.\" Copyright (C) 2022 Dylan Yudaken <dylany@fb.com>
+.\"
+.\" SPDX-License-Identifier: LGPL-2.0-or-later
+.\"
+.TH io_uring_cq_has_overflow 3 "September 5, 2022" "liburing-2.3" "liburing Manual"
+.SH NAME
+io_uring_cq_has_overflow \- returns if there are overflow entries waiting to move to the CQ ring
+.SH SYNOPSIS
+.nf
+.B #include <liburing.h>
+.PP
+.BI "bool io_uring_cq_has_overflow(const struct io_uring *" ring ");"
+.fi
+.SH DESCRIPTION
+.PP
+The
+.BR io_uring_cq_has_overflow (3)
+function informs the application if CQ entries have overflowed and are waiting to be flushed to
+the CQ ring. For example using
+.BR io_uring_get_events (3)
+.
+.SH RETURN VALUE
+True if there are CQ entries waiting to be flushed to the CQ ring.
+.SH SEE ALSO
+.BR io_uring_get_events (3)

data/vendor/liburing/man/io_uring_cq_ready.3

@@ -2,24 +2,25 @@
 .\"
 .\" SPDX-License-Identifier: LGPL-2.0-or-later
 .\"
-.TH io_uring_cq_ready "January 25, 2022" "liburing-2.1" "liburing Manual"
+.TH io_uring_cq_ready 3 "January 25, 2022" "liburing-2.1" "liburing Manual"
 .SH NAME
-io_uring_cq_ready - number of unconsumed ready entries in the CQ ring
+io_uring_cq_ready \- returns number of unconsumed ready entries in the CQ ring
 .SH SYNOPSIS
 .nf
-.BR "#include <liburing.h>"
+.B #include <liburing.h>
 .PP
-.BI "unsigned io_uring_cq_ready(const struct io_uring *ring)"
+.BI "unsigned io_uring_cq_ready(const struct io_uring *" ring ");"
 .fi
-.PP
 .SH DESCRIPTION
 .PP
-The io_uring_cq_ready() function retuns the number of unconsumed entries that
-are ready belonging to the
+The
+.BR io_uring_cq_ready (3)
+function returns the number of unconsumed entries that are ready belonging to the
 .I ring
 param.
 
 .SH RETURN VALUE
 Returns the number of unconsumed ready entries in the CQ ring.
 .SH SEE ALSO
-.BR io_uring_submit (3),  io_uring_wait_cqe (3)
+.BR io_uring_submit (3),
+.BR io_uring_wait_cqe (3)

data/vendor/liburing/man/io_uring_cqe_get_data.3

@@ -4,31 +4,50 @@
 .\"
 .TH io_uring_cqe_get_data 3 "November 15, 2021" "liburing-2.1" "liburing Manual"
 .SH NAME
-io_uring_cqe_get_data - get user data for completion event
+io_uring_cqe_get_data \- get user data for completion event
 .SH SYNOPSIS
 .nf
-.BR "#include <liburing.h>"
+.B #include <liburing.h>
 .PP
-.BI "void *io_uring_cqe_get_data(struct io_uring_cqe *cqe)"
+.BI "void *io_uring_cqe_get_data(struct io_uring_cqe *" cqe ");"
+.BI "
+.BI "__u64 io_uring_cqe_get_data64(struct io_uring_cqe *" cqe ");"
 .fi
-.PP
 .SH DESCRIPTION
 .PP
-The io_uring_cqe_get_data() function returns the user_data
-with the completion queue entry
-.I cqe.
+The
+.BR io_uring_cqe_get_data (3)
+function returns the user_data with the completion queue entry
+.IR cqe
+as a data pointer.
+
+The
+.BR io_uring_cqe_get_data64 (3)
+function returns the user_data with the completion queue entry
+.IR cqe
+as a 64-bit data value.
 
-After the caller has received a completion queue entry (CQE) with io_uring_wait_cqe(),
-he can call he io_uring_cqe_get_data() function to retrieve the
+After the caller has received a completion queue entry (CQE) with
+.BR io_uring_wait_cqe (3),
+the application can call
+.BR io_uring_cqe_get_data (3)
+or
+.BR io_uring_cqe_get_data64 (3)
+function to retrieve the
 .I user_data
 value. This requires that
 .I user_data
-has been set earlier with the function io_uring_sqe_set_data().
+has been set earlier with the function
+.BR io_uring_sqe_set_data (3)
+or
+.BR io_uring_sqe_set_data64 (3).
 
 .SH RETURN VALUE
 If the
 .I user_data
-value has been set before submitting the request, it will be returned. Otherwise
-the functions returns NULL.
+value has been set before submitting the request, it will be returned.
+Otherwise the functions returns NULL.
 .SH SEE ALSO
-.BR io_uring_get_sqe (3), io_uring_sqe_set_data (3),  io_uring_sqe_submit(3)
+.BR io_uring_get_sqe (3),
+.BR io_uring_sqe_set_data (3),
+.BR io_uring_sqe_submit (3)

data/vendor/liburing/man/io_uring_cqe_get_data64.3

@@ -0,0 +1 @@
+io_uring_cqe_get_data.3

data/vendor/liburing/man/io_uring_cqe_seen.3

@@ -4,29 +4,39 @@
 .\"
 .TH io_uring_cqe_seen 3 "November 15, 2021" "liburing-2.1" "liburing Manual"
 .SH NAME
-io_uring_cqe_seen - Mark io_uring completion event as processed
+io_uring_cqe_seen \- mark io_uring completion event as consumed
 .SH SYNOPSIS
 .nf
-.BR "#include <liburing.h>"
+.B #include <liburing.h>
 .PP
-.BI "void io_uring_cqe_seen(struct io_uring *ring,"
-.BI "                       struct io_uring_cqe *cqe)"
+.BI "void io_uring_cqe_seen(struct io_uring *" ring ","
+.BI "                       struct io_uring_cqe *" cqe ");"
 .fi
-.PP
 .SH DESCRIPTION
 .PP
-The io_uring_cqe_seen() function marks the IO completion
+The
+.BR io_uring_cqe_seen (3)
+function marks the IO completion
 .I cqe
 belonging to the
 .I ring
-param as processed.
+param as consumed.
 
-After the caller has submitted a request with io_uring_submit(), he can retrieve
-the completion with io_uring_wait_cqe() and mark it then as processed with
-io_uring_cqe_seen().
+After the caller has submitted a request with
+.BR io_uring_submit (3),
+the application can retrieve the completion with
+.BR io_uring_wait_cqe (3),
+.BR io_uring_peek_cqe (3),
+or any of the other CQE retrieval helpers, and mark it as consumed with
+.BR io_uring_cqe_seen (3).
 
-Completions must be marked as completed, so their slot can get reused.
+Completions must be marked as completed so their slot can get reused.
 .SH RETURN VALUE
 None
 .SH SEE ALSO
-.BR io_uring_submit (3),  io_uring_wait_cqe(3)
+.BR io_uring_submit (3),
+.BR io_uring_wait_cqe (3),
+.BR io_uring_peek_cqe (3),
+.BR io_uring_wait_cqes (3),
+.BR io_uring_wait_cqe_timeout (3),
+.BR io_uring_cqe_seen (3)

data/vendor/liburing/man/io_uring_enter.2

@@ -3,27 +3,31 @@
 .\"
 .\" SPDX-License-Identifier: LGPL-2.0-or-later
 .\"
-.TH IO_URING_ENTER 2 2019-01-22 "Linux" "Linux Programmer's Manual"
+.TH io_uring_enter 2 2019-01-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
 io_uring_enter \- initiate and/or complete asynchronous I/O
 .SH SYNOPSIS
 .nf
-.BR "#include <linux/io_uring.h>"
+.BR "#include <liburing.h>"
 .PP
 .BI "int io_uring_enter(unsigned int " fd ", unsigned int " to_submit ,
 .BI "                   unsigned int " min_complete ", unsigned int " flags ,
 .BI "                   sigset_t *" sig );
+.PP
+.BI "int io_uring_enter2(unsigned int " fd ", unsigned int " to_submit ,
+.BI "                    unsigned int " min_complete ", unsigned int " flags ,
+.BI "                    sigset_t *" sig ", size_t " sz );
 .fi
 .PP
 .SH DESCRIPTION
 .PP
-.BR io_uring_enter ()
+.BR io_uring_enter (2)
 is used to initiate and complete I/O using the shared submission and
 completion queues setup by a call to
 .BR io_uring_setup (2).
 A single call can both submit new I/O and wait for completions of I/O
 initiated by this call or previous calls to
-.BR io_uring_enter ().
+.BR io_uring_enter (2).
 
 .I fd
 is the file descriptor returned by
@@ -34,7 +38,7 @@ specifies the number of I/Os to submit from the submission queue.
 is a bitmask of the following values:
 .TP
 .B IORING_ENTER_GETEVENTS
-If this flag is set, then the system call will wait for the specificied
+If this flag is set, then the system call will wait for the specified
 number of events in
 .I min_complete
 before returning. This flag can be set along with
@@ -61,12 +65,12 @@ Since kernel 5.11, the system calls arguments have been modified to look like
 the following:
 
 .nf
-.BI "int io_uring_enter(unsigned int " fd ", unsigned int " to_submit ,
-.BI "                   unsigned int " min_complete ", unsigned int " flags ,
-.BI "                   const void *" arg ", size_t " argsz );
+.BI "int io_uring_enter2(unsigned int " fd ", unsigned int " to_submit ,
+.BI "                    unsigned int " min_complete ", unsigned int " flags ,
+.BI "                    const void *" arg ", size_t " argsz );
 .fi
 
-which is behaves just like the original definition by default. However, if
+which behaves just like the original definition by default. However, if
 .B IORING_ENTER_EXT_ARG
 is set, then instead of a
 .I sigset_t
@@ -93,6 +97,13 @@ is set to a valid pointer, then this time value indicates the timeout for
 waiting on events. If an application is waiting on events and wishes to
 stop waiting after a specified amount of time, then this can be accomplished
 directly in version 5.11 and newer by using this feature.
+.TP
+.B IORING_ENTER_REGISTERED_RING
+If the ring file descriptor has been registered through use of
+.B IORING_REGISTER_RING_FDS,
+then setting this flag will tell the kernel that the
+.I ring_fd
+passed in is the registered ring offset rather than a normal file descriptor.
 
 .PP
 .PP
@@ -130,12 +141,12 @@ is a pointer to a signal mask (see
 if
 .I sig
 is not NULL,
-.BR io_uring_enter ()
+.BR io_uring_enter (2)
 first replaces the current signal mask by the one pointed to by
 .IR sig ,
 then waits for events to become available in the completion queue, and
 then restores the original signal mask.  The following
-.BR io_uring_enter ()
+.BR io_uring_enter (2)
 call:
 .PP
 .in +4n
@@ -242,7 +253,7 @@ and
 .BR pwritev2 (2).
 If the file is not seekable,
 .I off
-must be set to zero.
+must be set to zero or -1.
 
 .TP
 .B IORING_OP_READ_FIXED
@@ -383,12 +394,46 @@ holds the flags associated with the system call. See also
 .BR sendmsg (2)
 for the general description of the related system call. Available since 5.3.
 
+This command also supports the following modifiers in
+.I ioprio:
+
+.PP
+.in +12
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently full and attempting to
+send data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a send of the data when there is enough space available.
+This initial send attempt can be wasteful for the case where the socket
+is expected to be full, setting this flag will bypass the initial send
+attempt and go straight to arming poll. If poll does indicate that data can
+be sent, the operation will proceed.
+.EE
+.in
+.PP
+
 .TP
 .B IORING_OP_RECVMSG
 Works just like IORING_OP_SENDMSG, except for
 .BR recvmsg(2)
 instead. See the description of IORING_OP_SENDMSG. Available since 5.3.
 
+This command also supports the following modifiers in
+.I ioprio:
+
+.PP
+.in +12
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently empty and attempting to
+receive data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a receive of the data when the socket has data to be read.
+This initial receive attempt can be wasteful for the case where the socket
+is expected to be empty, setting this flag will bypass the initial receive
+attempt and go straight to arming poll. If poll does indicate that data is
+ready to be received, the operation will proceed.
+.EE
+.in
+.PP
+
 .TP
 .B IORING_OP_SEND
 Issue the equivalent of a
@@ -405,12 +450,46 @@ holds the flags associated with the system call. See also
 .BR send(2)
 for the general description of the related system call. Available since 5.6.
 
+This command also supports the following modifiers in
+.I ioprio:
+
+.PP
+.in +12
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently full and attempting to
+send data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a send of the data when there is enough space available.
+This initial send attempt can be wasteful for the case where the socket
+is expected to be full, setting this flag will bypass the initial send
+attempt and go straight to arming poll. If poll does indicate that data can
+be sent, the operation will proceed.
+.EE
+.in
+.PP
+
 .TP
 .B IORING_OP_RECV
 Works just like IORING_OP_SEND, except for
 .BR recv(2)
 instead. See the description of IORING_OP_SEND. Available since 5.6.
 
+This command also supports the following modifiers in
+.I ioprio:
+
+.PP
+.in +12
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently empty and attempting to
+receive data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a receive of the data when the socket has data to be read.
+This initial receive attempt can be wasteful for the case where the socket
+is expected to be empty, setting this flag will bypass the initial receive
+attempt and go straight to arming poll. If poll does indicate that data is
+ready to be received, the operation will proceed.
+.EE
+.in
+.PP
+
 .TP
 .B IORING_OP_TIMEOUT
 This command will register a timeout operation. The
@@ -434,7 +513,7 @@ clock source. The request will complete with
 if the timeout got completed through expiration of the timer, or
 .I 0
 if the timeout got completed through requests completing on their own. If
-the timeout was cancelled before it expired, the request will complete with
+the timeout was canceled before it expired, the request will complete with
 .I -ECANCELED.
 Available since 5.4.
 
@@ -453,7 +532,7 @@ suspend while having a timeout request in-flight.
 
 .B IORING_TIMEOUT_REALTIME
 If set, then the clocksource used is
-.I CLOCK_BOOTTIME
+.I CLOCK_REALTIME
 instead of
 .I CLOCK_MONOTONIC.
 .EE
@@ -469,7 +548,7 @@ operation.
 must contain the
 .I user_data
 field of the previously issued timeout operation. If the specified timeout
-request is found and cancelled successfully, this request will terminate
+request is found and canceled successfully, this request will terminate
 with a result value of
 .I 0
 If the timeout request was found but expiration was already in progress,
@@ -535,16 +614,16 @@ Attempt to cancel an already issued request.
 .I addr
 must contain the
 .I user_data
-field of the request that should be cancelled. The cancellation request will
+field of the request that should be canceled. The cancelation request will
 complete with one of the following results codes. If found, the
 .I res
 field of the cqe will contain 0. If not found,
 .I res
-will contain -ENOENT. If found and attempted cancelled, the
+will contain -ENOENT. If found and attempted canceled, the
 .I res
 field will contain -EALREADY. In this case, the request may or may not
 terminate. In general, requests that are interruptible (like socket IO) will
-get cancelled, while disk IO requests cannot be cancelled if already started.
+get canceled, while disk IO requests cannot be canceled if already started.
 Available since 5.5.
 
 .TP
@@ -562,9 +641,9 @@ If used, the timeout specified in the command will cancel the linked command,
 unless the linked command completes before the timeout. The timeout will
 complete with
 .I -ETIME
-if the timer expired and the linked request was attempted cancelled, or
+if the timer expired and the linked request was attempted canceled, or
 .I -ECANCELED
-if the timer got cancelled because of completion of the linked request. Like
+if the timer got canceled because of completion of the linked request. Like
 .B IORING_OP_TIMEOUT
 the clock source used is
 .B CLOCK_MONOTONIC
@@ -778,7 +857,7 @@ contains the read or write offset. If
 .I fd
 does not refer to a seekable file,
 .I off
-must be set to zero. If
+must be set to zero or -1. If
 .I offs
 is set to
 .B -1
@@ -1045,9 +1124,124 @@ set, and a
 field matching the
 .I off
 value being passed in. This request type can be used to either just wake or
-interrupt anyone waiting for completions on the target ring, ot it can be used
+interrupt anyone waiting for completions on the target ring, or it can be used
 to pass messages via the two fields. Available since 5.18.
 
+.TP
+.B IORING_OP_SOCKET
+Issue the equivalent of a
+.BR socket(2)
+system call.
+.I fd
+must contain the communication domain,
+.I off
+must contain the communication type,
+.I len
+must contain the protocol, and
+.I rw_flags
+is currently unused and must be set to zero. See also
+.BR socket(2)
+for the general description of the related system call. Available since 5.19.
+
+If the
+.I file_index
+field is set to a positive number, the file won't be installed into the
+normal file table as usual but will be placed into the fixed file table at index
+.I file_index - 1.
+In this case, instead of returning a file descriptor, the result will contain
+either 0 on success or an error. If the index points to a valid empty slot, the
+installation is guaranteed to not fail. If there is already a file in the slot,
+it will be replaced, similar to
+.B IORING_OP_FILES_UPDATE.
+Please note that only io_uring has access to such files and no other syscall
+can use them. See
+.B IOSQE_FIXED_FILE
+and
+.B IORING_REGISTER_FILES.
+
+Available since 5.19.
+
+.TP
+.B IORING_OP_SEND_ZC
+Issue the zerocopy equivalent of a
+.BR send(2)
+system call. Similar to IORING_OP_SEND, but tries to avoid making intermediate
+copies of data. Zerocopy execution is not guaranteed and may fall back to
+copying. The request may also fail with
+.B -EOPNOTSUPP ,
+when a protocol doesn't support zerocopy, in which case users are recommended
+to use copying sends instead.
+
+The
+.I flags
+field of the first
+.I "struct io_uring_cqe"
+may likely contain
+.B IORING_CQE_F_MORE ,
+which means that there will be a second completion event / notification for
+the request, with the
+.I user_data
+field set to the same value. The user must not modify the data buffer until the
+notification is posted. The first cqe follows the usual rules and so its
+.I res
+field will contain the number of bytes sent or a negative error code. The
+notification's
+.I res
+field will be set to zero and the
+.I flags
+field will contain
+.B IORING_CQE_F_NOTIF .
+The two step model is needed because the kernel may hold on to buffers for a
+long time, e.g. waiting for a TCP ACK, and having a separate cqe for request
+completions allows userspace to push more data without extra delays. Note,
+notifications are only responsible for controlling the lifetime of the buffers,
+and as such don't mean anything about whether the data has atually been sent
+out or received by the other end. Even errored requests may generate a
+notification, and the user must check for
+.B IORING_CQE_F_MORE
+rather than relying on the result.
+
+.I fd
+must be set to the socket file descriptor,
+.I addr
+must contain a pointer to the buffer,
+.I len
+denotes the length of the buffer to send, and
+.I msg_flags
+holds the flags associated with the system call. When
+.I addr2
+is non-zero it points to the address of the target with
+.I addr_len
+specifying its size, turning the request into a
+.BR sendto(2)
+system call equivalent.
+
+Available since 6.0.
+
+This command also supports the following modifiers in
+.I ioprio:
+
+.PP
+.in +12
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently full and attempting to
+send data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a send of the data when there is enough space available.
+This initial send attempt can be wasteful for the case where the socket
+is expected to be full, setting this flag will bypass the initial send
+attempt and go straight to arming poll. If poll does indicate that data can
+be sent, the operation will proceed.
+
+.B IORING_RECVSEND_FIXED_BUF
+If set, instructs io_uring to use a pre-mapped buffer. The
+.I buf_index
+field should contain an index into an array of fixed buffers. See
+.BR io_uring_register (2)
+for details on how to setup a context for fixed buffer I/O.
+.EE
+.in
+.PP
+
 .PP
 The
 .I flags
@@ -1131,12 +1325,12 @@ opcode specific and is the same as with breaking chains of
 One special case is when the request has a linked timeout, then the CQE
 generation for the linked timeout is decided solely by whether it has
 .B IOSQE_CQE_SKIP_SUCCESS
-set, regardless whether it timed out or was cancelled. In other words, if a
+set, regardless whether it timed out or was canceled. In other words, if a
 linked timeout has the flag set, it's guaranteed to not post a CQE.
 
 The semantics are chosen to accommodate several use cases. First, when all but
 the last request of a normal link without linked timeouts are marked with the
-flag, only one CQE per lin is posted. Additionally, it enables supression of
+flag, only one CQE per lin is posted. Additionally, it enables suppression of
 CQEs in cases where the side effects of a successfully executed operation is
 enough for userspace to know the state of the system. One such example would
 be writing to a synchronisation file.
@@ -1247,7 +1441,9 @@ is used for certain commands, like
 .B IORING_OP_POLL_ADD
 or in conjunction with
 .B IOSQE_BUFFER_SELECT
-, see those entries.
+or
+.B IORING_OP_MSG_RING,
+, see those entries for details.
 .I res
 is the operation-specific result, but io_uring-specific errors
 (e.g. flags or opcode invalid) are returned through this field.
@@ -1273,7 +1469,7 @@ in the matching man page for that type, or in the opcodes section above for
 io_uring-specific opcodes.
 .PP
 .SH RETURN VALUE
-.BR io_uring_enter ()
+.BR io_uring_enter (2)
 returns the number of I/Os successfully consumed.  This can be zero
 if
 .I to_submit
@@ -1290,15 +1486,14 @@ completion queue entry (see section
 rather than through the system call itself.
 
 Errors that occur not on behalf of a submission queue entry are returned via the
-system call directly. On such an error,
-.B -1
-is returned and
+system call directly. On such an error, a negative error code is returned. The
+caller should not rely on
 .I errno
-is set appropriately.
+variable.
 .PP
 .SH ERRORS
 These are the errors returned by
-.BR io_uring_enter ()
+.BR io_uring_enter (2)
 system call.
 .TP
 .B EAGAIN
@@ -1317,8 +1512,30 @@ is a valid file descriptor, but the io_uring ring is not in the right state
 .BR io_uring_register (2)
 for details on how to enable the ring.
 .TP
+.B EBADR
+At least one CQE was dropped even with the
+.B IORING_FEAT_NODROP
+feature, and there are no otherwise available CQEs. This clears the error state
+and so with no other changes the next call to
+.BR io_uring_setup (2)
+will not have this error. This error should be extremely rare and indicates the
+machine is running critically low on memory and. It may be reasonable for the
+application to terminate running unless it is able to safely handle any CQE
+being lost.
+.TP
+.B EBUSY
+If the
+.B IORING_FEAT_NODROP
+feature flag is set, then
 .B EBUSY
-The application is attempting to overcommit the number of requests it can have
+will be returned if there were overflow entries,
+.B IORING_ENTER_GETEVENTS
+flag is set and not all of the overflow entries were able to be flushed to
+the CQ ring.
+
+Without
+.B IORING_FEAT_NODROP
+the application is attempting to overcommit the number of requests it can have
 pending. The application should wait for some completions and try again. May
 occur if the application tries to queue more requests than we have room for in
 the CQ ring, or if the application attempts to wait for more events without

data/vendor/liburing/man/io_uring_enter2.2

@@ -0,0 +1 @@
+io_uring_enter.2

data/vendor/liburing/man/io_uring_free_probe.3

@@ -2,23 +2,26 @@
 .\"
 .\" SPDX-License-Identifier: LGPL-2.0-or-later
 .\"
-.TH io_uring_free_probe "January 25, 2022" "liburing-2.1" "liburing Manual"
+.TH io_uring_free_probe 3 "January 25, 2022" "liburing-2.1" "liburing Manual"
 .SH NAME
-io_uring_free_probe - free probe instance
+io_uring_free_probe \- free probe instance
 .SH SYNOPSIS
 .nf
-.BR "#include <liburing.h>"
+.B #include <liburing.h>
 .PP
-.BI "void io_uring_free_probe(struct io_uring_probe *probe)"
+.BI "void io_uring_free_probe(struct io_uring_probe *" probe ");"
 .fi
-.PP
 .SH DESCRIPTION
 .PP
-The function io_uring_free_probe() frees the
+The function
+.BR io_uring_free_probe (3)
+frees the
 .I probe
-instance allocated with the io_uring_get_probe() function.
+instance allocated with the
+.BR io_uring_get_probe (3)
+function.
 
 .SH RETURN VALUE
 None
 .SH SEE ALSO
-.BR io_uring_get_probe (3)
+.BR io_uring_get_probe (3)