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

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

[Karl Mehltretter]

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.

Tested with QEMU 11.0.2, arm64 virt/cortex-a57, two vCPUs,
CONFIG_IO_URING=y, and CONFIG_PREEMPT=y:

  v7.3: close returned in 0 ms
  d135ab453a74: close returned after 2005 ms, immediately after B resumed

Regards,
Karl

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

[Jens Axboe]

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