Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2013, 17:16 UTC
Message-ID: <xmqqeh9p8ut3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CA+55aFzQhJqE4QDwJDKtkTtJpMNbz3_Aw5_Q3yTk5DnhLJyjCQ@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 10 quoted lines

> I hate your patch for other reasons, though:
>
>> The problem for read() is addressed in a similar way by introducing
>> a wrapper function in compat that always reads less than 2GB.
>
> Why do you do that? We already _have_ wrapper functions for read(),
> namely xread().  Exactly because you basically have to, in order to
> handle signals on interruptible filesystems (which aren't POSIX
> either, but at least sanely so) or from other random sources. And to
> handle the "you can't do reads that big" issue.

The same argument applies to xwrite(), but currently we explicitly catch EINTR and EAGAIN knowing that on sane systems these are the signs that we got interrupted.

Do we catch EINVAL unconditionally in the same codepath? Could EINVAL on saner systems mean completely different thing (like our caller is passing bogus parameters to underlying read/write, which is a program bug we would want to catch)?

Show 5 quoted lines

> So why isn't the patch much more straightforward? Like the attached
> totally untested one that just limits the read/write size to 8MB
> (which is totally arbitrary, but small enough to not have any latency
> issues even on slow disks, and big enough that any reasonable IO
> subsystem will still get good throughput).

Ahh. OK, not noticing EINVAL unconditionally, but always feed IOs in chunks that are big enough for sane systems but small enough for broken ones.

That makes sense.  Could somebody on MacOS X test this?

Thanks.