diff options
author | Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> | 2021-09-03 22:24:36 +0800 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2021-09-03 08:27:49 -0600 |
commit | 31efe48eb5dc4de3e31e84b54f287e9665410ab3 (patch) | |
tree | 6798f43ad37efb84383e6f49735ec8f9251a5afa /fs/gfs2/incore.h | |
parent | 8d4ad41e3e8e4b907f088f25aee4a92f3f864027 (diff) |
io_uring: fix possible poll event lost in multi shot mode
IIUC, IORING_POLL_ADD_MULTI is similar to epoll's edge-triggered mode,
that means once one pure poll request returns one event(cqe), we'll
need to read or write continually until EAGAIN is returned, then I think
there is a possible poll event lost race in multi shot mode:
t1 poll request add | |
t2 | |
t3 event happens | |
t4 task work add | |
t5 | task work run |
t6 | commit one cqe |
t7 | | user app handles cqe
t8 | new event happen |
t9 | add back to waitqueue |
t10 |
After t6 but before t9, if new event happens, there'll be no wakeup
operation, and if user app has picked up this cqe in t7, read or write
until EAGAIN is returned. In t8, new event happens and will be lost,
though this race window maybe small.
To fix this possible race, add poll request back to waitqueue before
committing cqe.
Fixes: 88e41cf928a6 ("io_uring: add multishot mode for IORING_OP_POLL_ADD")
Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20210903142436.5767-1-xiaoguang.wang@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'fs/gfs2/incore.h')
0 files changed, 0 insertions, 0 deletions