On 12/9/24 23:43, Gabriel Krisman Bertazi wrote:
From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
This command spawns a short lived asynchronous context to execute
following linked operations. Once the link is completed, the task
terminates. This is specially useful to create new processes, by
linking an IORING_OP_EXEC at the end of the chain. In this case, the
task doesn't terminate, but returns to userspace, starting the new
process.
This is different from the existing io workqueues in a few ways: First,
it is completely separated from the io-wq code, and the task cannot be
reused by a future link; Second, the task doesn't share the FDT, and
other process structures with the rest of io_uring (except for the
memory map); Finally, because of the limited context, it doesn't support
executing requests asynchronously and requeing them. Every request must
complete at ->issue time, or fail. It also doesn't support task_work
execution, for a similar reason. The goal of this design allowing the
user to close file descriptors, release locks and do other cleanups
right before switching to a new process.
A big pitfall here, in my (Gabriel) opinion, is how this duplicates the
logic of io_uring linked request dispatching. I'd suggest I merge this
into the io-wq code, as a special case of workqueue. But I'd like to get
feedback on this idea from the maintainers before moving further with the
implementation.
Signed-off-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
Co-developed-by: Gabriel Krisman Bertazi <krisman@xxxxxxx>
Signed-off-by: Gabriel Krisman Bertazi <krisman@xxxxxxx>
---
...
+static int io_uring_spawn_task(void *data)
+{
+ struct io_kiocb *head = data;
+ struct io_clone *c = io_kiocb_to_cmd(head, struct io_clone);
+ struct io_ring_ctx *ctx = head->ctx;
+ struct io_kiocb *req, *next;
+ int err;
+
+ set_task_comm(current, "iou-spawn");
+
+ mutex_lock(&ctx->uring_lock);
+
+ for (req = c->link; req; req = next) {
+ int hardlink = req->flags & REQ_F_HARDLINK;
+
+ next = req->link;
+ req->link = NULL;
+ req->flags &= ~(REQ_F_HARDLINK | REQ_F_LINK);
Do you allow linked timeouts? If so, it'd need to take the lock.
Also, the current link impl assumes that the list only modified
when all refs to the head request are put, you can't just do it
without dropping refs first or adjusting the rest of core link
handling.
+
+ if (!(req->flags & REQ_F_FAIL)) {
+ err = io_issue_sqe(req, IO_URING_F_COMPLETE_DEFER);
There should never be non IO_URING_F_NONBLOCK calls with ->uring_lock.
I'd even say that opcode handling shouldn't have any business with
digging so deep into internal infra, submitting requests, flushing
caches, processing links and so on. It complicates things.
Take defer taskrun, io_submit_flush_completions() will not wake
waiters, and we probably have or will have a bunch of optimisations
that it can break.
Also, do you block somewhere all other opcodes? If it's indeed
an under initialised task then it's not safe to run most of them,
and you'd never know in what way, unfortunately. An fs write
might need a net namespace, a send/recv might decide to touch
fs_struct and so on.
+ /*
+ * We can't requeue a request from the spawn
+ * context. Fail the whole chain.
+ */
+ if (err) {
+ req_fail_link_node(req, -ECANCELED);
+ io_req_complete_defer(req);
+ }
+ }
+ if (req->flags & REQ_F_FAIL) {
+ if (!hardlink) {
+ fail_link(next);
+ break;
+ }
+ }
+ }
+
+ io_submit_flush_completions(ctx);
Ordering with
+ percpu_ref_put(&ctx->refs);
+
+ mutex_unlock(&ctx->uring_lock);
+
+ force_exit_sig(SIGKILL);
+ return 0;
+}
+
+int io_clone_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
+{
+ if (unlikely(sqe->fd || sqe->ioprio || sqe->addr2 || sqe->addr
+ || sqe->len || sqe->rw_flags || sqe->buf_index
+ || sqe->optlen || sqe->addr3))
+ return -EINVAL;
+
+ if (unlikely(!(req->flags & (REQ_F_HARDLINK|REQ_F_LINK))))
+ return -EINVAL;
+
+ if (unlikely(req->ctx->submit_state.link.head))
+ return -EINVAL;
+
+ return 0;
+}
+
+int io_clone(struct io_kiocb *req, unsigned int issue_flags)
+{
+ struct io_clone *c = io_kiocb_to_cmd(req, struct io_clone);
+ struct task_struct *tsk;
+
+ /* It is possible that we don't have any linked requests, depite
+ * checking during ->prep(). It would be harmless to continue,
+ * but we don't need even to create the worker thread in this
+ * case.
+ */
+ if (!req->link)
+ return IOU_OK;
+
+ /*
+ * Prevent the context from going away before the spawned task
+ * has had a chance to execute. Dropped by io_uring_spawn_task.
+ */
+ percpu_ref_get(&req->ctx->refs);
+
+ tsk = create_io_uring_spawn_task(io_uring_spawn_task, req);
+ if (IS_ERR(tsk)) {
+ percpu_ref_put(&req->ctx->refs);
+
+ req_set_fail(req);
+ io_req_set_res(req, PTR_ERR(tsk), 0);
+ return PTR_ERR(tsk);
+ }
+
+ /*
+ * Steal the link from the io_uring dispatcher to have them
+ * submitted through the new thread. Note we can no longer fail
+ * the clone, so the spawned task is responsible for completing
+ * these requests.
+ */
+ c->link = req->link;
+ req->flags &= ~(REQ_F_HARDLINK | REQ_F_LINK);
+ req->link = NULL;
+
+ wake_up_new_task(tsk);
I assume from here onwards io_uring_spawn_task() might be
running in parallel. You're passing the req inside but free
it below by returning OK. Is there anything that prevents
io_uring_spawn_task() from accessing an already deallocated
request?
+
+ return IOU_OK;
+
+}
diff --git a/io_uring/spawn.h b/io_uring/spawn.h
new file mode 100644
index 000000000000..9b7ddb776d1e
--- /dev/null
+++ b/io_uring/spawn.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+/*
+ * Spawning a linked series of operations onto a dedicated task.
+ *
+ * Copyright © 2022 Josh Triplett
+ */
+
+int io_clone_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe);
+int io_clone(struct io_kiocb *req, unsigned int issue_flags);
--
Pavel Begunkov
