On 5/28/20 7:51 PM, Jens Axboe wrote: > The poll based retry handler uses the same logic as the normal poll > requests, but the latter triggers a completion if we hit the slim > race of: > > 1a) data/space isn't available > 2a) data/space becomes available > 1b) arm poll handler (returns success, callback not armed) > > This isn't the case for the task_work based retry, where we need to > take action if the event triggered in the short time between trying > and arming the poll handler. > > Catch this case in __io_arm_poll_handler(), and queue the task_work > upfront instead of depending on the waitq handler triggering it. The > latter isn't armed at this point. Disregard this one, I don't think this race exists. If we hit the poll->head != NULL case, then we definitely added the waitq. And if the list is empty once we're under the lock, we already triggered the callback and queued the task_work. -- Jens Axboe
