On 2/23/25 22:35, David Wei wrote:
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.
FWIW, either option is probably fine if it's for internal
handling and not uapi.
--
Pavel Begunkov
