On 3/10/22 9:28 AM, Artyom Pavlov wrote: >>> 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? > > Ah, indeed. I've missed that EBADFD and EOVERFLOW errors only can > happen in the submitter ring, so the receiver ring can always > interpret CQE with the IORING_CQE_F_MSG flag as a successfully > received message from another ring. Yes, so I don't think there's any confusion there. I did just make the prep helper in liburing take an unsigned, and I did test that we don't have any issues on that front. Posted v2, passes testing too. I actually think this is quite a nifty feature, and can be used quite flexibly to communicate between rings. -- Jens Axboe
