On 3/23/21 4:52 AM, Pavel Begunkov wrote: > WARNING: CPU: 1 PID: 27907 at fs/io_uring.c:7147 io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 > CPU: 1 PID: 27907 Comm: iou-sqp-27905 Not tainted 5.12.0-rc4-syzkaller #0 > RIP: 0010:io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 > Call Trace: > io_ring_ctx_wait_and_kill+0x214/0x700 fs/io_uring.c:8619 > io_uring_release+0x3e/0x50 fs/io_uring.c:8646 > __fput+0x288/0x920 fs/file_table.c:280 > task_work_run+0xdd/0x1a0 kernel/task_work.c:140 > io_run_task_work fs/io_uring.c:2238 [inline] > io_run_task_work fs/io_uring.c:2228 [inline] > io_uring_try_cancel_requests+0x8ec/0xc60 fs/io_uring.c:8770 > io_uring_cancel_sqpoll+0x1cf/0x290 fs/io_uring.c:8974 > io_sqpoll_cancel_cb+0x87/0xb0 fs/io_uring.c:8907 > io_run_task_work_head+0x58/0xb0 fs/io_uring.c:1961 > io_sq_thread+0x3e2/0x18d0 fs/io_uring.c:6763 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > > May happen that last ctx ref is killed in io_uring_cancel_sqpoll(), so > fput callback (i.e. io_uring_release()) is enqueued through task_work, > and run by same cancellation. As it's deeply nested we can't do parking > or taking sqd->lock there, because its state is unclear. So avoid > ctx ejection from sqd list from io_ring_ctx_wait_and_kill() and do it > in a clear context in io_ring_exit_work(). Applied, thanks. -- Jens Axboe
