summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2023-01-20 23:08:21 +0100
committerJens Axboe <axboe@kernel.dk>2023-01-20 23:11:54 +0100
commit8caa03f10bf92cb8657408a6ece6a8a73f96ce13 (patch)
tree4966ad5c97201debcb18607e0c6feeafeaa202de
parentio_uring/msg_ring: fix remote queue to disabled ring (diff)
downloadlinux-8caa03f10bf92cb8657408a6ece6a8a73f96ce13.tar.xz
linux-8caa03f10bf92cb8657408a6ece6a8a73f96ce13.zip
io_uring/poll: don't reissue in case of poll race on multishot request
A previous commit fixed a poll race that can occur, but it's only applicable for multishot requests. For a multishot request, we can safely ignore a spurious wakeup, as we never leave the waitqueue to begin with. A blunt reissue of a multishot armed request can cause us to leak a buffer, if they are ring provided. While this seems like a bug in itself, it's not really defined behavior to reissue a multishot request directly. It's less efficient to do so as well, and not required to rearm anything like it is for singleshot poll requests. Cc: stable@vger.kernel.org Fixes: 6e5aedb9324a ("io_uring/poll: attempt request issue after racy poll wakeup") Reported-and-tested-by: Olivier Langlois <olivier@trillion01.com> Link: https://github.com/axboe/liburing/issues/778 Signed-off-by: Jens Axboe <axboe@kernel.dk>
-rw-r--r--io_uring/poll.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/io_uring/poll.c b/io_uring/poll.c
index 32e5fc8365e6..2ac1366adbd7 100644
--- a/io_uring/poll.c
+++ b/io_uring/poll.c
@@ -283,8 +283,12 @@ static int io_poll_check_events(struct io_kiocb *req, bool *locked)
* to the waitqueue, so if we get nothing back, we
* should be safe and attempt a reissue.
*/
- if (unlikely(!req->cqe.res))
+ if (unlikely(!req->cqe.res)) {
+ /* Multishot armed need not reissue */
+ if (!(req->apoll_events & EPOLLONESHOT))
+ continue;
return IOU_POLL_REISSUE;
+ }
}
if (req->apoll_events & EPOLLONESHOT)
return IOU_POLL_DONE;