With the move to private task_work, SQPOLL neglected to also run the normal task_work, if any is pending. This will eventually get run, but we should run it with the private task_work to ensure that things like a final fput() is processed in a timely fashion. Cc: stable@xxxxxxxxxxxxxxx Link: https://lore.kernel.org/all/313824bc-799d-414f-96b7-e6de57c7e21d@xxxxxxxxx/ Reported-by: Andrew Udvare <audvare@xxxxxxxxx> Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Tested-by: Christian Heusel <christian@xxxxxxxxx> Tested-by: Andrew Udvare <audvare@xxxxxxxxx> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> --- V2: move the task_work_run() section so we're always guaranteed it runs after any task_work. Ran the previous test cases again, both the yarn based one and the liburing test case, and they still work as they should. Previously, if we had a retry condition due to being flooded with task_work, then we'd not run the kernel side task_work. diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c index 554c7212aa46..b3722e5275e7 100644 --- a/io_uring/sqpoll.c +++ b/io_uring/sqpoll.c @@ -238,11 +238,13 @@ static unsigned int io_sq_tw(struct llist_node **retry_list, int max_entries) if (*retry_list) { *retry_list = io_handle_tw_list(*retry_list, &count, max_entries); if (count >= max_entries) - return count; + goto out; max_entries -= count; } - *retry_list = tctx_task_work_run(tctx, max_entries, &count); +out: + if (task_work_pending(current)) + task_work_run(); return count; } -- Jens Axboe
