Re: [REGRESSION] io_uring: final close can hang on a stopped submitter

[Jens Axboe <axboe@kernel.dk>]

On 10/26/26 10:35 PM, Karl Mehltretter wrote:
> Commit 13d3783a55b7 ("io_uring: wait for in-flight requests on ring
> release") can make the final close of a shared ring wait for task_work
> owned by a stopped submitter. The close does not return until that task
> resumes.
> 
> An LLM helped with the review and reproducer.
> 
> #regzbot introduced: 13d3783a55b758a9fa05b67835afa7e216476c61
> 
> Last good: v7.3, c03c1a14507dfaf8b856c2608f9ac216021fc222
> Tested bad: d135ab453a7400a34930bdda1ef4bdc8acfac80e
>             (master as of 2026-10-27)
> 
> The reproducer uses a default ring and three processes:
> 
>   1. Submitter B creates the ring and submits POLL_ADD on an empty pipe.
>   2. B forks closer A. A inherits the ring fd but starts without an
>      io_uring task context.
>   3. A unmaps the ring but keeps its fd. B drops its fd and mappings,
>      then stops itself with SIGSTOP.
>   4. After confirming that B is stopped, controller P tells A to close
>      the final ring fd.
>   5. P resumes B after two seconds so the test can finish.
> 
> B keeps both pipe ends open and remains alive until close returns. This
> excludes pipe HUP and process exit as completion sources.

This is working as intended. With the change, close() waits for
requests still in flight, as otherwise they keep files pinned after
the ring is gone. If you SIGSTOP a task, then that task can't run
the required work to complete it. A fatal signal will still kill
it.

Unsurprisingly, sending SIGSTOP to something may prevent it from
doing work...

-- 
Jens Axboe