From: rsbecker@nexbridge.com Date: Wed, 08 Apr 2026 20:08:55 GMT Subject: RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327 Message-ID: <014e01dcc793$8a9bab90$9fd302b0$@nexbridge.com> In-Reply-To: On April 8, 2026 2:13 PM, Junio C Hamano wrote: >Jeff King writes: > >> On Wed, Apr 08, 2026 at 12:25:47PM -0400, rsbecker@nexbridge.com wrote: >> >>> This is also impacting t5608 and t7700. Anywhere where writev() is >>> used, seemingly. We went through MAX_IO_SIZE issues years ago, >>> instead of using ssize_t as a basis of how big communication is. I >>> think >>> writev() is not valid. It worked on Lunix, but had issues elsewhere. >>> This broke the compat layer. >> >> I wondered briefly if the problem could be that we're violating >> MAX_IO_SIZE here, as our use of writev() does not respect it at all. >> But the only spot that uses it is feeding pkt-line packets, which max >> out at 64k. So unless your MAX_IO_SIZE is smaller than that, I doubt >> that is the problem. > >Good point. The original did not use write(2) directly but used write_or_die(), that >is write_in_full(), that loops over xwrite(), so it would have worked even with a lot >lower MAX_IO_SIZE limit. > >According to man7.org, writev() is allowed to transfer fewer bytes than requested, >so our use of writev() may have to be a bit more careful, though. On my box, I have the following note: Specifying the sum of the iov_len values in the iov array greater than the OSS I/O size limit for that open causes the writev() function to return -1 and set errno to [EINVAL]. This can be either 52K (SSIZE_MAX) or 868K depending on the build settings. We are currently stuck with 32-bit builds, with large file support, so really no limit on the file sizes, but due to dependencies that are stuck at 32-bit until I convince the powers that be to fix those. Please, can we be compliant with MAX_IO_SIZE?