Re: [PATCH] io_uring/io-wq: avoid repeated task_work scans during teardown
"changfengnan" <[email protected]>
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.e79dfdc8.0374.4705.bd44.702afa9fc1bd@bytedance.com> |
Hi Peter & Steven: Do you have time to help review this patch ? Thanks. > From: "Jens Axboe"<[email protected]> > Date: Fri, May 22, 2026, 00:59 > Subject: Re: [PATCH] io_uring/io-wq: avoid repeated task_work scans during teardown > To: "Fengnan Chang"<[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> > On 5/19/26 9:12 PM, Fengnan Chang wrote: > > We hit hard-lockup reports from iou-wrk threads stuck in > > task_work_cancel_match() during io-wq teardown in syzkaller test. > > The root cause is that teardown repeatedly rescans the submitter task's > > full task_work list under pi_lock, once per matched item. > > > > Two spots are problematic: > > > > 1) io_wq_cancel_tw_create() loops calling task_work_cancel_match() to > > remove worker-creation callbacks one at a time. Each call re-walks > > the entire list from scratch while holding pi_lock. > > > > 2) io_worker_exit() unconditionally scans the submitter task_work list > > for its own create_work, even when it never queued one. With many > > workers exiting simultaneously against a large unrelated task_work > > list, this adds up fast. > > > > Fix (1) by adding task_work_cancel_match_all() that unlinks all matching > > callbacks in a single traversal, then iterating the returned list locally. > > Same try_cmpxchg() synchronisation as before, stops at the work_exited > > sentinel. > > > > Fix (2) by skipping the cancel entirely unless create_state indicates a > > pending create_work. Since create_state is exclusively owned via > > test_and_set_bit_lock, at most one callback can be queued per worker, so > > the cancel is also simplified from a loop to a single call. > > > > With this fix the reproducer (FIFO-open + MSG_RING SEND_FD stress) no > > longer triggers hard-lockup reports, and task_work_cancel_match samples > > drop to microseconds. > > Looks good to me, nicer way to do this too. > > -- > Jens Axboe >