From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Patrick Steinhardt <ps@pks.im>,
git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>,
"Randall S. Becker" <randall.becker@nexbridge.ca>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] wrapper: properly handle MAX_IO_SIZE in `write_in_full()`
Date: Thu, 09 Apr 2026 13:40:36 -0700 [thread overview]
Message-ID: <xmqq5x5zsw8r.fsf@gitster.g> (raw)
In-Reply-To: <20260409202329.GA3076846@coredump.intra.peff.net> (Jeff King's message of "Thu, 9 Apr 2026 16:23:29 -0400")
Jeff King <peff@peff.net> writes:
> On Thu, Apr 09, 2026 at 09:42:42AM -0700, Junio C Hamano wrote:
>
>> > + for (i = 0, total_length = 0; i < iovcnt; i++) {
>> > + if (unsigned_add_overflows(total_length, iov[i].iov_len))
>> > + break;
>>
>> We add .iov_len up in this first loop, because we do not want to
>> bust writev(3p)'s limit.
>>
>> EINVAL The sum of the iov_len values in the iov array would
>> overflow an ssize_t.
>>
>> cf. https://pubs.opengroup.org/onlinepubs/9799919799/functions/writev.html
>>
>> As the width of ssize_t in bits can be a lot smaller than size_t,
>> the above "unsigned_add_overflows() triggers way too late for the
>> check to matter, no?
>
> I think it is correct as-is.
>
> The real check against ssize_t is later, when we compare total_length to
> MAX_IO_SIZE (which is clamped to SSIZE_MAX). So this is just making sure
> we do not overflow size_t when counting up the total (and if we do, we
> _know_ we are going to overflow ssize_t, which must be smaller).
But then what happens after it breaks out of the loop? We cannot be
at i==0, so let's say we have a reasonably small iov[0] and iov[1]
that is so large and makes size_t wraparound. We break out here,
and then send the iov[0] with writev(). But have we checked if
iov[0] is under MAX_IO_SIZE in that case before calling writev()?
> I think this can be made more clear by counting down allowable bytes
> instead of up. I'll show an example in a second.
>
>> > + }
>> > +
>> > + if (i < iovcnt) {
>> > + /*
>> > + * The first entry exceeds MAX_IO_SIZE, so we pass it to
>> > + * xwrite, which knows to handle this case.
>> > + */
>> > + if (!i)
>> > + return xwrite(fd, iov->iov_base, iov->iov_len);
>>
>> Ben has a similar comment, but it would be easier to see the
>> correspondence if you rephrase the comment perhaps like
>> [...]
>
> Me three. I think this can be made more clear if we bail to xwrite()
> immediately in the loop. So together with the count-down, something
> like:
>
> ssize_t allowed = MAX_IO_SIZE;
> int i;
>
> for (i = 0; i < iovcnt; i++) {
> if (iov[i].iov_len > allowed) {
> if (!i)
> return xwrite(fd, iov->iov_base, iov_len);
> break;
> }
> allowed -= iov[i].iov_len;
> }
> return writev(fd, iov, i);
I agree that this is much simpler to follow.
next prev parent reply other threads:[~2026-04-09 20:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 12:47 [PATCH] wrapper: properly handle MAX_IO_SIZE in `write_in_full()` Patrick Steinhardt
2026-04-09 15:46 ` Ben Knoble
2026-04-09 16:42 ` Junio C Hamano
2026-04-09 20:23 ` Jeff King
2026-04-09 20:40 ` Junio C Hamano [this message]
2026-04-09 20:59 ` Jeff King
2026-04-09 21:09 ` Junio C Hamano
2026-04-10 5:19 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5x5zsw8r.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
--cc=randall.becker@nexbridge.ca \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox