summaryrefslogtreecommitdiff
path: root/fs/gfs2/incore.h
diff options
context:
space:
mode:
authorXiaoguang Wang <xiaoguang.wang@linux.alibaba.com>2021-09-03 22:24:36 +0800
committerJens Axboe <axboe@kernel.dk>2021-09-03 08:27:49 -0600
commit31efe48eb5dc4de3e31e84b54f287e9665410ab3 (patch)
tree6798f43ad37efb84383e6f49735ec8f9251a5afa /fs/gfs2/incore.h
parent8d4ad41e3e8e4b907f088f25aee4a92f3f864027 (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