Feature request: extend cancellation capabilities OR direct descriptor duplication

[bnbajwa]

Hi,

I wanted to cancel specifically a multishot recv SQE but encountered difficulty.

Currently, the following options are available for SQE cancellation:

1. io_uring_prep_cancel: With this method, my SQE would need to be identified by the user_data field. However, the problem is that my user_data values are not guaranteed to be unique. There is a possibility that I might end up canceling a different SQE that happens to have the same user_data value. To ensure uniqueness, I could make a memory allocation for each SQE and use the address of the allocation as the user_data value. However, I prefer to avoid unnecessary allocations if I can fit all the required data within the user_data field (up to 8 bytes), which can result in non-unique user_data values.

2. io_uring_prep_cancel_fd -- This method matches the SQE(s) based on the file descriptor used in the original request. The issue here is that I typically have other SQEs associated with the same file descriptor, such as send and recv operations on a TCP socket. And again, I might end up cancelling a different SQE than intended.

Feature request (my problem would be easily solved if we had any one of these features):

1. Ability to duplicate direct descriptors (similar to the dup() function for regular file descriptors). This would allow me to create a new duplicated file descriptor specifically for the multishot recv SQE. If I wanted to cancel it, I could use the io_uring_prep_cancel_fd method with the duplicated file descriptor.
2. Ability to cancel an SQE by matching both the file descriptor and the SQE type (e.g. IORING_OP_RECV). This would provide a more precise cancellation mechanism.

Thanks, let me know what your thoughts

[axboe]

I think adding an op match for cancelation makes the most sense, both for your case and in general. Let me take a look at it...

[axboe]

Here's a branch on top of what's queued for 6.5, the top two patches add op based canceling:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-cancel-op

Ran a brief test and it seems to work for me. You'd just do:

sqe->cancel_flags |= IORING_ASYNC_CANCEL_OP;
sqe->len = <opcode to cancel>

after doing an io_uring_prep_cancel64() on the sqe.

[axboe]

Needs a new flag to match multiple cases, I'll do that next. Eg for matching both fd and op. What does work is doing op based cancel, if you can identify that uniquely with user_data && op.

[axboe]

Above branch has been updated now, with support for matching specific keys. So you can now decide if you want to match on user_data, fd, or opcode - and any combination of those. Eg if you want to match on opcode and fd, you'd set

IORING_ASYNC_CANCEL_FD | IORING_ASYNC_CANCEL_OP

in the cancel flags, basically you can combine any of these and use the new IORING_ASYNC_CANCEL_USERDATA as well. To be backwards compatible, if we're not matching on FD or OP specifically, then user_data match is the default regardless if whether or not IORING_ASYNC_CANCEL_USERDATA is set.

Also contains some cancel cleanup patches at the start, the last two requests are really the meat of it.

[axboe]

Series posted as well: https://lore.kernel.org/io-uring/[email protected]/

[bnbajwa]

nice, thanks!

will test it today/over the weekend

[bnbajwa]

I've tested it and it works well for me