On 3/10/22 9:22 AM, Artyom Pavlov wrote: >>> I like IORING_OP_WAKEUP_RING with sqe->len being copied to >>> cqe->result. The only question I have is how should "negative" (i.e. >>> bigger or equal to 2^31) lengths be handled. They either should be >>> copied similarly to positive values or we should get an error. >> >> Any IO transferring syscall in Linux supports INT_MAX as the maximum in >> one request, which is also why the res field is sized the way it is. So >> you cannot transfer more than that anyway, hence it should not be an >> issue (at least specific to io_uring). >> >>> Also what do you think about registering ring fds? Could it be >>> beneficial? >> >> Definitely, it'll make the overhead a bit lower for issuing the >> IORING_OP_MSG_RING (it's been renamed ;-) request. >> > > I mean the case when sqe->len is used to transfer arbitrary data set > by user. I believe IORING_OP_MSG_RING behavior for this edge case > should be explicitly documented. Ah gotcha > It looks like we have 3 options: > 1) Copy sqe->len to cqe->result without any checks. Disadvantage: > user-provided value may collide with EBADFD and EOVERFLOW. > 2) Submit error CQE to the submitter ring. > 3) Submit error CQE to the receiver ring (cqe->result will contain > error code). #1 should not be an issue, as cqe->result for those values is the original ring result code, not the target ring. I'd say the application should just case it to u32 and intepret it like that, if it's worried about the signed nature of it? -- Jens Axboe
