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

[Karl Mehltretter <kmehltretter@gmail.com>]

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