From: Junio C Hamano Date: Wed, 08 Apr 2026 21:43:20 GMT Subject: Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327 Message-ID: In-Reply-To: <016b01dcc79e$87472860$95d57920$@nexbridge.com> writes: > On April 8, 2026 4:22 PM, Junio C Hamano wrote: >> writes: >> >>> 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]. >> >>That is unexpected. >> >>writev() may fail if the sum of iov_len would not fit within ssize_t with > EINVAL, but >>unless your "the OSS I/O size limit" is the same as SSIZE_MAX, what you > have above >>is not quite the same. >> >>Does your build work with NO_WRITEV=Nope? I think I saw it asked a few > times >>but I do not recall seeing it answered. At least we know >>xwrite() seems to work well enough on your system, which is what the >>writev() emulation is written in terms of, so I suspect it would. > > Yes, NO_WRITEV=Nope does compile and execute. I am including it > in our CI/CD job for now. Can we plan on a fix for this? What I have heard so far indicate that the code that uses writev() would need to loop over to prepare for short writes, but your writev() that fails for "the OSS I/O size limit" (whatever it is) does not sound like something we want to change the callers to chomp the writev() calls into smaller chunks for. Such a platform is far better off using the compat/writev for the code path we recently started using writev() in. To be quite honest, I am not sure if it is even worth using writev() if we need a loop that protects against shrot writes, so unless I am grossly mistaken (e.g., perhaps there is some guarantee that there won't be any short writes for writev() that sends data smaller than 64k that I missed in the docs), the best course of action might be to revert the change to use writev() and use the two write(2)s as before, *if* we actually observe that the current code is broken by short writes.