[PATCH 0/2] io_uring: add schedule points to request freeing loops

[Yuanhe Shu <xiangzao@linux.alibaba.com>]

An I/O stress test on a production v6.6-based debug kernel (stress-ng -a 1
--class io -t 7h on a 384-CPU machine) hit the soft lockup watchdog
twice.  The kernel was built with KASAN, kmemleak, lockdep and
CONFIG_PREEMPT_NONE=y.  Both lockups occurred while a CPU was busy
in an io_uring request freeing loop that has no scheduling point:

1) A stress-ng worker looped in io_free_batch_list(), reached from
   exit-time task_work, until the machine panicked on "softlockup:
   hung tasks".

2) A completion fallback work item held uring_lock for 671 seconds
   in that same free loop, until the watchdog fired again
   ("BUG: soft lockup - CPU#61 stuck for 671s").

The field kernel is v6.6-based, so to check whether the same
weakness exists in current mainline, I tried to reproduce the
pattern on v7.3-rc7 on a 192-CPU debug kernel (KASAN, kmemleak,
lockdep; preempt=none - see the note below), with a test
that submits 32K requests per ring and then kills the rings.  I
don't know whether real workloads hit these exact loops on
mainline as hard as our test does, but the loops clearly have the
same unbounded shape:

- A single io_free_batch_list() call freeing a 32K completion batch
  took 443ms with no scheduling point in between.

- Killing 48 rings at once made one __io_req_caches_free() call
  drain a single cache for up to 13 seconds, with 8 kworkers each
  stuck for over 12 seconds; a separate run with 96 rings produced
  97 soft lockup warnings during teardown (the stack is in patch 2).

With this series applied, the same 96-ring run produces zero
kworker soft lockup warnings: all 97 drain-path warnings are gone.
This series targets the request freeing and cache draining paths;
the submission loop itself may need a separate treatment and is
intentionally left out of this series.

The free loops are the remaining gap: the CQ overflow flush already
drops the lock and reschedules (eac2ca2d682f), and io_add_buffers(),
io_remove_buffers_legacy(), the fdinfo dump loops and the tctx
teardown all iterate with a cond_resched() in the loop.  These two
request freeing loops have none.  The debug options amplify the
per-request cost, but the loops are otherwise bounded only by the
number of completed or cached requests.  No functional change is
intended; the patches only add scheduling points to long loops,
and cond_resched() only invokes the scheduler if need_resched()
is set.  Unlike the overflow flush resched point, these do not drop
the lock or leave any critical section, so they introduce no
reordering concerns.

Note: the mainline test was booted with preempt=none to match
the production kernel above.  On x86 this required a local Kconfig
adjustment to disable PREEMPT_LAZY; this is a test-environment
detail and does not change the fix.  cond_resched() is the standard
schedule point on PREEMPT_NONE/VOLUNTARY kernels.

Tested with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING
enabled; no might_sleep or scheduling-while-atomic warnings during
the reproduction runs.

Yuanhe Shu (2):
  io_uring: add a schedule point in io_free_batch_list()
  io_uring: add a schedule point in __io_req_caches_free()

 io_uring/io_uring.c | 2 ++
 1 file changed, 2 insertions(+)

base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
-- 
2.43.7