SQE timeout with IORING_TIMEOUT_ETIME_SUCCESS set return a CQE with res field equal to -ETIME about liburing HOT 4 OPEN

The man page is wrong. What the flag means is that dependent links for this SQE will not get failed in case of -ETIME, the request itself will still be posting -ETIME as the result code.

from liburing.

The man page is wrong, it's supposed to return -ETIME even with IORING_TIMEOUT_ETIME_SUCCESS.
The flag has never been changing the return code, the only effect is that it doesn't break links. E.g.

sqe = io_uring_get_sqe();
prep_timeout(sqe, flags = 0);
sqe->flags |= IOSQE_LINK;

sqe = io_uring_get_sqe();
prep_read(sqe);

Here the read would never be executed, you'd usually get something like cqe1.res = -ETIME, cqe2.res = -ECANCELED.
If you pass IORING_TIMEOUT_ETIME_SUCCESS, however, you would expect the read to be actually run.

from liburing.

The man page is wrong, it's supposed to return -ETIME even with IORING_TIMEOUT_ETIME_SUCCESS. The flag has never been changing the return code, the only effect is that it doesn't break links. E.g.

sqe = io_uring_get_sqe();
prep_timeout(sqe, flags = 0);
sqe->flags |= IOSQE_LINK;

sqe = io_uring_get_sqe();
prep_read(sqe);

Here the read would never be executed, you'd usually get something like cqe1.res = -ETIME, cqe2.res = -ECANCELED. If you pass IORING_TIMEOUT_ETIME_SUCCESS, however, you would expect the read to be actually run.

Using io_uring_prep_link_timeout to Control Dependent Task Timeout vs. prep_timeout -> (linked) -> read op

What's the difference between using io_uring_prep_link_timeout to control the timeout of a dependent task and using prep_timeout -> (linked) -> read op?

I found that io_uring_prep_link_timeout is not always able to cancel the dependent task.

from liburing.

Here the read would never be executed, you'd usually get something like cqe1.res = -ETIME, cqe2.res = -ECANCELED. If you pass IORING_TIMEOUT_ETIME_SUCCESS, however, you would expect the read to be actually run.

Using io_uring_prep_link_timeout to Control Dependent Task Timeout vs. prep_timeout -> (linked) -> read op

What do you mean by "Control Dependent Task Timeout"? I can assume "Dependent Task" is a linked request, but even then I don't understand what it means.

What's the difference between using io_uring_prep_link_timeout to control the timeout of a dependent task and using prep_timeout -> (linked) -> read op?

I found that io_uring_prep_link_timeout is not always able to cancel the dependent task.

The only situation it can legally happen is if the timeout fired when the request it's linked to has already been completed but not yet removed. Something like this:

CPU1                |   CPU2
execute_request();  |
complete_request()  |
  post_cqe();       |
                    |   linked timeout triggered
  cancel_timeout()  |

And it's perfectly ok. Apps can think as if the request got completed before timeout. If you see any other cases, let us know.

from liburing.