summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2020-12-17 17:10:18 -0700
committerJens Axboe <axboe@kernel.dk>2020-12-17 17:10:58 -0700
commit88b845dee001723c4a0db1fe5477de735b6d3bb0 (patch)
treec2c9b083a67da5fb3901c3fee36ac91e15b0f6a3
parent31a9f9cb495b468f3a93c4edaf8fccd65aa86f64 (diff)
downloadliburing-88b845dee001723c4a0db1fe5477de735b6d3bb0.tar.gz
liburing-88b845dee001723c4a0db1fe5477de735b6d3bb0.tar.bz2
src/queue: add comment on why reading SQ->head for flush isn't atomic
This has come up at least two times, add a comment there to explain exactly why the code is fine as-is. Fixes: https://github.com/axboe/liburing/issues/268 Signed-off-by: Jens Axboe <axboe@kernel.dk>
-rw-r--r--src/queue.c11
1 files changed, 11 insertions, 0 deletions
diff --git a/src/queue.c b/src/queue.c
index 8c4f373..16bd86b 100644
--- a/src/queue.c
+++ b/src/queue.c
@@ -225,6 +225,17 @@ int __io_uring_flush_sq(struct io_uring *ring)
*/
io_uring_smp_store_release(sq->ktail, ktail);
out:
+ /*
+ * This _may_ look problematic, as we're not supposed to be reading
+ * SQ->head without acquire semantics. When we're in SQPOLL mode, the
+ * kernel submitter could be updating this right now. For non-SQPOLL,
+ * task itself does it, and there's no potential face. But even for
+ * SQPOLL, the load is going to be potentially out-of-date the very
+ * instant it's done, regardless or whether or not it's done
+ * atomically. Worst case, we're going to be over-estimating what
+ * we can submit. The point is, we need to be able to deal with this
+ * situation regardless of any perceived atomicity.
+ */
return ktail - *sq->khead;
}