summaryrefslogtreecommitdiff
path: root/.gitattributes
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2022-06-18 10:00:50 -0600
committerJens Axboe <axboe@kernel.dk>2022-07-24 18:39:15 -0600
commit78a861b9495920f8609dee5b670dacbff09d359f (patch)
tree77a78d66954b73d2e2467aa08b451b3485bc4d88 /.gitattributes
parent7d8ca7250197096bfa9f432c1d99b0555504bbba (diff)
downloadlinux-78a861b9495920f8609dee5b670dacbff09d359f.tar.gz
io_uring: add sync cancelation API through io_uring_register()
The io_uring cancelation API is async, like any other API that we expose there. For the case of finding a request to cancel, or not finding one, it is fully sync in that when submission returns, the CQE for both the cancelation request and the targeted request have been posted to the CQ ring. However, if the targeted work is being executed by io-wq, the API can only start the act of canceling it. This makes it difficult to use in some circumstances, as the caller then has to wait for the CQEs to come in and match on the same cancelation data there. Provide a IORING_REGISTER_SYNC_CANCEL command for io_uring_register() that does sync cancelations, always. For the io-wq case, it'll wait for the cancelation to come in before returning. The only expected returns from this API is: 0 Request found and canceled fine. > 0 Requests found and canceled. Only happens if asked to cancel multiple requests, and if the work wasn't in progress. -ENOENT Request not found. -ETIME A timeout on the operation was requested, but the timeout expired before we could cancel. and we won't get -EALREADY via this API. If the timeout value passed in is -1 (tv_sec and tv_nsec), then that means that no timeout is requested. Otherwise, the timespec passed in is the amount of time the sync cancel will wait for a successful cancelation. Link: https://github.com/axboe/liburing/discussions/608 Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions