]> git.baikalelectronics.ru Git - kernel.git/commit
io_uring/poll: allow some retries for poll triggering spuriously
authorJens Axboe <axboe@kernel.dk>
Sat, 25 Feb 2023 19:53:53 +0000 (12:53 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 11 Mar 2023 12:55:43 +0000 (13:55 +0100)
commit947fbff59e0c5268d60b9c4dc91f51cd2f21c401
tree9125037d0de710ce89d416bc400c1783a37bc6c2
parentedad69aa92472303e11cb19a936fa2177fd4a0e4
io_uring/poll: allow some retries for poll triggering spuriously

commit 480a3d3699fd4a16c5074e1ada20ae6a46e209e6 upstream.

If we get woken spuriously when polling and fail the operation with
-EAGAIN again, then we generally only allow polling again if data
had been transferred at some point. This is indicated with
REQ_F_PARTIAL_IO. However, if the spurious poll triggers when the socket
was originally empty, then we haven't transferred data yet and we will
fail the poll re-arm. This either punts the socket to io-wq if it's
blocking, or it fails the request with -EAGAIN if not. Neither condition
is desirable, as the former will slow things down, while the latter
will make the application confused.

We want to ensure that a repeated poll trigger doesn't lead to infinite
work making no progress, that's what the REQ_F_PARTIAL_IO check was
for. But it doesn't protect against a loop post the first receive, and
it's unnecessarily strict if we started out with an empty socket.

Add a somewhat random retry count, just to put an upper limit on the
potential number of retries that will be done. This should be high enough
that we won't really hit it in practice, unless something needs to be
aborted anyway.

Cc: stable@vger.kernel.org # v5.10+
Link: https://github.com/axboe/liburing/issues/364
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
io_uring/poll.c
io_uring/poll.h