2022-05-23 23:05:03 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
#
|
|
|
|
|
# Makefile for io_uring
|
|
|
|
|
|
2024-08-30 16:52:02 +00:00
|
|
|
ifdef CONFIG_GCOV_PROFILE_URING
|
|
|
|
|
GCOV_PROFILE := y
|
|
|
|
|
endif
|
|
|
|
|
|
2024-03-27 04:13:41 +00:00
|
|
|
obj-$(CONFIG_IO_URING) += io_uring.o opdef.o kbuf.o rsrc.o notif.o \
|
2025-05-09 11:03:28 +00:00
|
|
|
tctx.o filetable.o rw.o poll.o \
|
2024-06-03 17:51:19 +00:00
|
|
|
eventfd.o uring_cmd.o openclose.o \
|
|
|
|
|
sqpoll.o xattr.o nop.o fs.o splice.o \
|
|
|
|
|
sync.o msg_ring.o advise.o openclose.o \
|
2025-05-16 18:10:12 +00:00
|
|
|
statx.o timeout.o cancel.o \
|
2025-01-31 21:19:11 +00:00
|
|
|
waitid.o register.o truncate.o \
|
io_uring: introduce io_uring querying
There are many parameters users might want to query about io_uring like
available request types or the ring sizes. This patch introduces an
interface for such slow path queries.
It was written with several requirements in mind:
- Can be used with or without an io_uring instance. Asking for supported
setup flags before creating an instance as well as qeurying info about
an already created ring are valid use cases.
- Should be moderately fast. For example, users might use it to
periodically retrieve ring attributes at runtime. As a consequence,
it should be able to query multiple attributes in a single syscall.
- Backward and forward compatible.
- Should be reasobably easy to use.
- Reduce the kernel code size for introducing new query types.
It's implemented as a new registration opcode IORING_REGISTER_QUERY.
The user passes one or more query strutctures linked together, each
represented by struct io_uring_query_hdr. The header stores common
control fields needed for processing and points to query type specific
information.
The header contains
- The query type
- The result field, which on return contains the error code for the query
- Pointer to the query type specific information
- The size of the query structure. The kernel will only populate up to
the size, which helps with backward compatibility. The kernel can also
reduce the size, so if the current kernel is older than the inteface
the user tries to use, it'll get only the supported bits.
- next_entry field is used to chain multiple queries.
Apart from common registeration syscall failures, it can only immediately
return an error code in case when the headers are incorrect or any
other addresses and invalid. That usually mean that the userspace
doesn't use the API right and should be corrected. All query type
specific errors are returned in the header's result field.
As an example, the patch adds a single query type for now, i.e.
IO_URING_QUERY_OPCODES, which tells what register / request / etc.
opcodes are supported, but there are particular plans to extend it.
Note: there is a request probing interface via IORING_REGISTER_PROBE,
but it's a mess. It requires the user to create a ring first, it only
works for requests, and requires dynamic allocations.
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-07 23:03:00 +00:00
|
|
|
memmap.o alloc_cache.o query.o
|
2025-02-15 00:09:36 +00:00
|
|
|
obj-$(CONFIG_IO_URING_ZCRX) += zcrx.o
|
2022-05-23 23:05:03 +00:00
|
|
|
obj-$(CONFIG_IO_WQ) += io-wq.o
|
io_uring: add support for futex wake and wait
Add support for FUTEX_WAKE/WAIT primitives.
IORING_OP_FUTEX_WAKE is mix of FUTEX_WAKE and FUTEX_WAKE_BITSET, as
it does support passing in a bitset.
Similary, IORING_OP_FUTEX_WAIT is a mix of FUTEX_WAIT and
FUTEX_WAIT_BITSET.
For both of them, they are using the futex2 interface.
FUTEX_WAKE is straight forward, as those can always be done directly from
the io_uring submission without needing async handling. For FUTEX_WAIT,
things are a bit more complicated. If the futex isn't ready, then we
rely on a callback via futex_queue->wake() when someone wakes up the
futex. From that calback, we queue up task_work with the original task,
which will post a CQE and wake it, if necessary.
Cancelations are supported, both from the application point-of-view,
but also to be able to cancel pending waits if the ring exits before
all events have occurred. The return value of futex_unqueue() is used
to gate who wins the potential race between cancelation and futex
wakeups. Whomever gets a 'ret == 1' return from that claims ownership
of the io_uring futex request.
This is just the barebones wait/wake support. PI or REQUEUE support is
not added at this point, unclear if we might look into that later.
Likewise, explicit timeouts are not supported either. It is expected
that users that need timeouts would do so via the usual io_uring
mechanism to do that using linked timeouts.
The SQE format is as follows:
`addr` Address of futex
`fd` futex2(2) FUTEX2_* flags
`futex_flags` io_uring specific command flags. None valid now.
`addr2` Value of futex
`addr3` Mask to wake/wait
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-08 17:57:40 +00:00
|
|
|
obj-$(CONFIG_FUTEX) += futex.o
|
2025-01-31 21:19:11 +00:00
|
|
|
obj-$(CONFIG_EPOLL) += epoll.o
|
|
|
|
|
obj-$(CONFIG_NET_RX_BUSY_POLL) += napi.o
|
2025-05-09 11:03:28 +00:00
|
|
|
obj-$(CONFIG_NET) += net.o cmd_net.o
|
2025-05-16 18:10:12 +00:00
|
|
|
obj-$(CONFIG_PROC_FS) += fdinfo.o
|
2025-06-30 18:16:51 +00:00
|
|
|
obj-$(CONFIG_IO_URING_MOCK_FILE) += mock_file.o
|
