liburing icon indicating copy to clipboard operation
liburing copied to clipboard

Do not discard high 32 bits of length in send

Open bitonic opened this issue 5 months ago • 9 comments

Fixes #1435

bitonic avatar Jul 13 '25 17:07 bitonic

@axboe regarding branch or not branch: imo a predictable branch is better than a cmov (as in, it'll be cheaper in practice). But if you really care about having a cmov, I can make sure it compiles to that.

bitonic avatar Jul 13 '25 17:07 bitonic

I really think this should handle all the cases where this is true. And this is very much using a branch, even if it's marked unlikely. A cap function ala:

size_t mask = -(len > UINT32_MAX);
return (unsigned int )((len & ~mask) | (UINT32_MAX & mask));

would be more efficient, and that help can just be used anywhere.

Also note the format of git commits for liburing. Needs a proper commit subject, commit message, identity, and signed-off-by line.

axboe avatar Jul 13 '25 18:07 axboe

Gotta run for now, I'll check back in tomorrow.

axboe avatar Jul 13 '25 18:07 axboe

@axboe I've pushed the bit twiddly version. I've also amended all similar call sites I could find with a __u32.*len grep.

Should I just put the commit to be signed off by you?

bitonic avatar Jul 13 '25 18:07 bitonic

@axboe is anything holding up the merge (apart from the commit message, which I'll amend if you confirm that I should put it as signed off by you)?

bitonic avatar Jul 16 '25 14:07 bitonic

Sorry, OOO for a bit, back next week. Only thing holding this back is I'm still pondering if we shouldn't just document the fact that the API len is a 32-bit unsigned. I'm not really convinced that it's worth adding code to cap the transfer length.

axboe avatar Jul 17 '25 14:07 axboe

Sorry, OOO for a bit, back next week. Only thing holding this back is I'm still pondering if we shouldn't just document the fact that the API len is a 32-bit unsigned. I'm not really convinced that it's worth adding code to cap the transfer length.

I think silently dropping the high 32 bits is terrible, documentation notwithstanding. send doesn't do that, so people will reasonably assume that the io_uring version will do the same, and it's a condition that will happen very rarely.

Are you concerned about performance? Capping the length will be immaterial compared to the cost of the place/pickup of the SQE onto the ring anyway.

bitonic avatar Jul 17 '25 17:07 bitonic

I think io_uring_prep_fadvise/io_uring_prep_madvise/io_uring_prep_provide_buffers are a lot more dubious (it should really have been a 64-bit length all along). But for send/recv there are basically no downsides.

bitonic avatar Jul 17 '25 17:07 bitonic

@axboe any news? liburing is still silently broken (both in the docs and in the types) if you do large writes.

bitonic avatar Sep 12 '25 21:09 bitonic