On 2025-02-21 17:07, Jens Axboe wrote: > On 2/21/25 6:01 PM, Pavel Begunkov wrote: >> On 2/22/25 00:08, Jens Axboe wrote: >>> Just a few minor drive-by nits. >>> >>>> @@ -1250,6 +1251,12 @@ int io_recvzc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) >>>> zc->ifq = req->ctx->ifq; >>>> if (!zc->ifq) >>>> return -EINVAL; >>>> + zc->len = READ_ONCE(sqe->len); >>>> + if (zc->len == UINT_MAX) >>>> + return -EINVAL; >>>> + /* UINT_MAX means no limit on readlen */ >>>> + if (!zc->len) >>>> + zc->len = UINT_MAX; >>> >>> Why not just make UINT_MAX allowed, meaning no limit? Would avoid two >>> branches here, and as far as I can tell not really change anything in >>> terms of API niceness. >> >> I think 0 goes better as a special uapi value. It doesn't alter the >> uapi, and commonly understood as "no limits", which is the opposite >> to the other option, especially since UINT_MAX is not a max value for >> an unlimited request, I'd easily expect it to drive more than 4GB. > > Yeah that's certainly better, and as you say also has the same (forced) > semantics for multishot. > I thought about using 0 originally, but needed a way to distinguish 0 meaning no limit vs a limited read hitting 0 and completing. I could store a flag in the request at recvzc_prep() time as an alternative.
