summaryrefslogtreecommitdiffstats
path: root/io_uring/rw.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2023-01-10 18:44:37 +0100
committerJens Axboe <axboe@kernel.dk>2023-01-12 18:35:51 +0100
commit6e5aedb9324aab1c14a23fae3d8eeb64a679c20e (patch)
tree06e7fe8c6c4aaaaf2a3059e1d2cc6d4956a20794 /io_uring/rw.c
parentio_uring/fdinfo: include locked hash table in fdinfo output (diff)
downloadlinux-6e5aedb9324aab1c14a23fae3d8eeb64a679c20e.tar.xz
linux-6e5aedb9324aab1c14a23fae3d8eeb64a679c20e.zip
io_uring/poll: attempt request issue after racy poll wakeup
If we have multiple requests waiting on the same target poll waitqueue, then it's quite possible to get a request triggered and get disappointed in not being able to make any progress with it. If we race in doing so, we'll potentially leave the poll request on the internal tables, but removed from the waitqueue. That means that any subsequent trigger of the poll waitqueue will not kick that request into action, causing an application to potentially wait for completion of a request that will never happen. Fix this by adding a new poll return state, IOU_POLL_REISSUE. Rather than have complicated logic for how to re-arm a given type of request, just punt it for a reissue. While in there, move the 'ret' variable to the only section where it gets used. This avoids confusion the scope of it. Cc: stable@vger.kernel.org Fixes: eb0089d629ba ("io_uring: single shot poll removal optimisation") Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions