[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <176477359158.834078.5263900730628607784.b4-ty@kernel.dk>
Date: Wed, 03 Dec 2025 07:53:11 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: Uday Shankar <ushankar@...estorage.com>, io-uring@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] io_uring/io-wq: always retry worker create on
ERESTART*
On Tue, 02 Dec 2025 13:57:44 -0700, Caleb Sander Mateos wrote:
> If a task has a pending signal when create_io_thread() is called,
> copy_process() will return -ERESTARTNOINTR. io_should_retry_thread()
> will request a retry of create_io_thread() up to WORKER_INIT_LIMIT = 3
> times. If all retries fail, the io_uring request will fail with
> ECANCELED.
> Commit 3918315c5dc ("io-wq: backoff when retrying worker creation")
> added a linear backoff to allow the thread to handle its signal before
> the retry. However, a thread receiving frequent signals may get unlucky
> and have a signal pending at every retry. Since the userspace task
> doesn't control when it receives signals, there's no easy way for it to
> prevent the create_io_thread() failure due to pending signals. The task
> may also lack the information necessary to regenerate the canceled SQE.
> So always retry the create_io_thread() on the ERESTART* errors,
> analogous to what a fork() syscall would do. EAGAIN can occur due to
> various persistent conditions such as exceeding RLIMIT_NPROC, so respect
> the WORKER_INIT_LIMIT retry limit for EAGAIN errors.
>
> [...]
Applied, thanks!
[1/1] io_uring/io-wq: always retry worker create on ERESTART*
commit: 777dfd696d3db9b7b08a41c3c03554ce0ba6c94e
Best regards,
--
Jens Axboe
Powered by blists - more mailing lists