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. -- Jens Axboe
