From: Jens Axboe <axboe@kernel.dk>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Chris Mason <mason@kernel.org>, io-uring@vger.kernel.org
Subject: Re: [PATCH 08/10] io_uring/cancel: drop sqd->lock while SQPOLL waits
Date: Fri, 30 Oct 2026 14:04:19 -0600 [thread overview]
Message-ID: <22616bc6-a393-4dd2-bca1-8912cf2bf51f@kernel.dk> (raw)
In-Reply-To: <auTrEl1ahq53QKrz@gmail.com>
On 10/30/26 1:11 PM, Karl Mehltretter wrote:
> On Fri, Oct 30, 2026 at 07:34:06AM +0100, Jens Axboe wrote:
>> But no reason not to make the check see it. I've queued up the below,
>> what do you think? It sets IO_SQ_THREAD_SHOULD_STOP in io_sq_thread()
>> before it cancels, and tests that bit in io_sq_offload_create()
>> alongside sqd->thread. Then no new state needed.
>
> That looks good, except for the WARN_ON_ONCE() in io_sq_thread_stop()
> below.
>
>> diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
>> index 49c52284ecdd..c833e776320d 100644
>> --- a/io_uring/sqpoll.c
>> +++ b/io_uring/sqpoll.c
>> @@ -433,6 +433,12 @@ static int io_sq_thread(void *data)
>> if (io_sq_tw_pending())
>> io_sq_tw(UINT_MAX);
>>
>> + /*
>> + * Cancelation drops sqd->lock while it waits, and a ring could attach
>> + * to a thread that is on its way out. A fatal signal doesn't set the
>> + * bit, so set it here for io_sq_offload_create() to see.
>> + */
>> + set_bit(IO_SQ_THREAD_SHOULD_STOP, &sqd->state);
>> io_uring_cancel_generic(true, sqd);
>
> Setting IO_SQ_THREAD_SHOULD_STOP here on a fatal signal means
> io_sq_thread_stop() will see it already set when the last ring drops
> sqd->refs and trigger:
>
> WARN_ON_ONCE(test_bit(IO_SQ_THREAD_SHOULD_STOP, &sqd->state));
Want to send a patch against current master?
--
Jens Axboe
next prev parent reply other threads:[~2026-10-30 20:04 UTC|newest]
Thread overview: 15+ 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 ` [PATCH 08/10] io_uring/cancel: drop sqd->lock while SQPOLL waits Jens Axboe
2026-10-30 1:25 ` Karl Mehltretter
2026-10-30 13:34 ` Jens Axboe
2026-10-30 19:11 ` Karl Mehltretter
2026-10-30 20:04 ` Jens Axboe [this message]
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=22616bc6-a393-4dd2-bca1-8912cf2bf51f@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=kmehltretter@gmail.com \
--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.