From: Jens Axboe <axboe@kernel.dk>
To: io-uring@vger.kernel.org
Cc: Chris Mason <mason@kernel.org>, Jens Axboe <axboe@kernel.dk>
Subject: [PATCH 08/10] io_uring/cancel: drop sqd->lock while SQPOLL waits
Date: Wed, 28 Oct 2026 10:46:56 -0600 [thread overview]
Message-ID: <20261028164732.1264069-9-axboe@kernel.dk> (raw)
In-Reply-To: <20261028164732.1264069-1-axboe@kernel.dk>
From: Chris Mason <mason@kernel.org>
An exiting SQPOLL thread calls io_uring_cancel_generic() with sqd->lock
held, and keeps it across cond_resched() and the sleep until nothing is
in flight anymore. A zero-copy send notification can't be canceled and
stays pending as long as the peer doesn't read, so the lock is held for
as long as a user cares to. io_ring_exit_work() needs it to park the
thread, and so do IORING_REGISTER_IOWQ_AFF and IOWQ_MAX_WORKERS. With
64 such rings sharing the thread, every iou_exit slot sleeps on the lock
and no ring gets freed for anyone.
Drop the lock around cond_resched() and the sleep, like the main loop of
the thread does. Each walk of ctx_list is still under one hold, and
nothing is kept across the unlock. The thread drops its io-wq, frees its
tctx and clears sqd->thread under one hold after the loop, so whoever
holds the lock and finds sqd->thread set can still use them.
Fixes: 63809137ebb5 ("io_uring: flush notifiers after sendzc")
Signed-off-by: Chris Mason <mason@kernel.org>
[axboe: adapted to the schedule_timeout() based loop]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
io_uring/cancel.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/io_uring/cancel.c b/io_uring/cancel.c
index 6f7a6cf356c2..79b5c133319b 100644
--- a/io_uring/cancel.c
+++ b/io_uring/cancel.c
@@ -703,7 +703,16 @@ __cold void io_uring_cancel_generic(bool cancel_all, struct io_sq_data *sqd)
}
if (loop) {
+ /*
+ * A request that runs in io-wq and doesn't end makes
+ * each round come here. Don't hold sqd->lock for that
+ * long either.
+ */
+ if (sqd)
+ mutex_unlock(&sqd->lock);
cond_resched();
+ if (sqd)
+ mutex_lock(&sqd->lock);
continue;
}
@@ -741,7 +750,18 @@ __cold void io_uring_cancel_generic(bool cancel_all, struct io_sq_data *sqd)
if (state & TASK_INTERRUPTIBLE)
timeout = MAX_SCHEDULE_TIMEOUT;
+ /*
+ * A zero-copy notification can't be canceled, and a
+ * peer that doesn't read keeps it pending. Don't hold
+ * sqd->lock while waiting for it, or whoever wants the
+ * lock sleeps as long. No ring is used across this,
+ * the next round walks ->ctx_list anew.
+ */
+ if (sqd)
+ mutex_unlock(&sqd->lock);
schedule_timeout(timeout);
+ if (sqd)
+ mutex_lock(&sqd->lock);
}
end_wait:
finish_wait(&tctx->wait, &wait);
--
2.56.0
next prev parent reply other threads:[~2026-10-28 16:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 16:46 [PATCHSET 0/10] Various io_uring fixes Jens Axboe
2026-10-28 16:46 ` [PATCH 01/10] io_uring/io-wq: no new workers once the exit has begun Jens Axboe
2026-10-28 16:46 ` [PATCH 02/10] io_uring/rsrc: charge buffer arrays and nodes to memcg Jens Axboe
2026-10-28 16:46 ` [PATCH 03/10] io_uring: charge tctx nodes and personalities Jens Axboe
2026-10-28 16:46 ` [PATCH 04/10] io_uring: free XArray nodes left by a failed store Jens Axboe
2026-10-28 16:46 ` [PATCH 05/10] io_uring/bpf-ops: clear bpf_ctx while submitting SQEs Jens Axboe
2026-10-28 16:46 ` [PATCH 06/10] io_uring: free the task context after a grace period Jens Axboe
2026-10-28 16:46 ` [PATCH 07/10] io_uring/sqpoll: don't wait for the thread to exit Jens Axboe
2026-10-28 16:46 ` Jens Axboe [this message]
2026-10-30 1:25 ` [PATCH 08/10] io_uring/cancel: drop sqd->lock while SQPOLL waits Karl Mehltretter
2026-10-28 16:46 ` [PATCH 09/10] io_uring/io-wq: save worker type before dropping its reference Jens Axboe
2026-10-28 16:46 ` [PATCH 10/10] io_uring: defer foreign io-wq enqueues to task_work Jens Axboe
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=20261028164732.1264069-9-axboe@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=mason@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.