All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Joachim Schmitz <jojo@schmitz-digital.de>
Cc: git@vger.kernel.org
Subject: Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Date: Wed, 11 Feb 2015 15:15:47 -0800	[thread overview]
Message-ID: <xmqq1tlwt4yk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <loom.20150211T230519-703@post.gmane.org> (Joachim Schmitz's message of "Wed, 11 Feb 2015 22:05:50 +0000 (UTC)")

Joachim Schmitz <jojo@schmitz-digital.de> writes:

> Joachim Schmitz <jojo <at> schmitz-digital.de> writes:
>
>> 
>> Junio C Hamano <gitster <at> pobox.com> writes:
>> 
>> <snip> 
>> > OK, then let's do this.
>> > 
>
>
> Except for the type "taht"

Also #ifndef part X-<

Here is what I queued for the day.

-- >8 --
Subject: xread/xwrite: clip MAX_IO_SIZE to SSIZE_MAX

Since 0b6806b9 (xread, xwrite: limit size of IO to 8MB, 2013-08-20),
we chomp our calls to read(2) and write(2) into chunks of
MAX_IO_SIZE bytes (8 MiB), because a large IO results in a bad
latency when the program needs to be killed.  This also brought our
IO below SSIZE_MAX, which is a limit POSIX allows read(2) and
write(2) to fail when the IO size exceeds it, for OS X, where a
problem was originally reported.

However, there are other systems that define SSIZE_MAX smaller than
our default, and feeding 8 MiB to underlying read(2)/write(2) would
fail.  Make sure we clip our calls to the lower limit as well.

Reported-by: Joachim Schmitz <jojo@schmitz-digital.de>
Helped-by: Torsten Bögershausen <tboegi@web.de>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 wrapper.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/wrapper.c b/wrapper.c
index f92b147..c77c2eb 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -135,8 +135,21 @@ void *xcalloc(size_t nmemb, size_t size)
  * 64-bit is buggy, returning EINVAL if len >= INT_MAX; and even in
  * the absense of bugs, large chunks can result in bad latencies when
  * you decide to kill the process.
+ *
+ * We pick 8 MiB as our default, but if the platform defines SSIZE_MAX
+ * that is smaller than that, clip it to SSIZE_MAX, as a call to
+ * read(2) or write(2) larger than that is allowed to fail.  As the last
+ * resort, we allow a port to pass via CFLAGS e.g. "-DMAX_IO_SIZE=value"
+ * to override this, if the definition of SSIZE_MAX platform is broken.
  */
-#define MAX_IO_SIZE (8*1024*1024)
+#ifndef MAX_IO_SIZE
+# define MAX_IO_SIZE_DEFAULT (8*1024*1024)
+# if defined(SSIZE_MAX) && (SSIZE_MAX < MAX_IO_SIZE_DEFAULT)
+#  define MAX_IO_SIZE SSIZE_MAX
+# else
+#  define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT
+# endif
+#endif
 
 /*
  * xread() is the same a read(), but it automatically restarts read()
-- 
2.3.0-186-g9f73ee1

  reply	other threads:[~2015-02-11 23:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-07 16:45 read() MAX_IO_SIZE bytes, more than SSIZE_MAX? Joachim Schmitz
2015-02-07 16:48 ` Joachim Schmitz
2015-02-07 17:19 ` Torsten Bögershausen
2015-02-07 17:29   ` Joachim Schmitz
2015-02-07 18:03     ` Joachim Schmitz
2015-02-07 20:32     ` Torsten Bögershausen
2015-02-07 22:13       ` Junio C Hamano
2015-02-07 22:31         ` Joachim Schmitz
2015-02-08  2:13           ` Junio C Hamano
2015-02-08  2:32             ` Randall S. Becker
2015-02-08 12:05             ` Joachim Schmitz
2015-02-08 17:09               ` Eric Sunshine
2015-02-11 21:13                 ` Junio C Hamano
2015-02-11 21:29                   ` Joachim Schmitz
2015-02-11 22:05                     ` Joachim Schmitz
2015-02-11 23:15                       ` Junio C Hamano [this message]
2015-02-07 18:06   ` Randall S. Becker
2015-02-07 18:20     ` Randall S. Becker
2015-02-07 18:36       ` Joachim Schmitz
2015-02-07 19:14 ` Joachim Schmitz
  -- strict thread matches above, loose matches on Subject: below --
2015-02-12  7:46 Joachim Schmitz

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=xmqq1tlwt4yk.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jojo@schmitz-digital.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.