From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Git mailing list" <git@vger.kernel.org>,
"Clemens Buchacher" <drizzd@gmx.net>,
"Duy Nguyen" <pclouds@gmail.com>
Subject: Re: [PATCH 2/2] fetch: ignore SIGPIPE during network operation
Date: Mon, 4 Mar 2019 23:11:39 -0500 [thread overview]
Message-ID: <20190305041139.GA19800@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqk1hfzbn1.fsf@gitster-ct.c.googlers.com>
On Mon, Mar 04, 2019 at 10:11:46AM +0900, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... But by dying immediately, we never actually
> > read the ERR packet and report its content to the user. This is a (racy)
> > problem on all platforms.
>
> Yeah, I do not think of a good solution for it (nor I am not
> convinced that it is worth fixing, to be honest. The cable may get
> cut before we have a chance to see the ERR packet, or the other side
> may have died before producing one.
We definitely can never cover this 100%. But I wonder if we could put a
little more effort into "best effort". Specifically, I was thinking that
on seeing the write error, we might do something like:
void NORETURN last_ditch_proto_read(const char *msg)
{
char *line;
/*
* we had a write error; see if the server sent us anything
* useful to report
*/
if (packet_read_line_gently(fd, NULL, &line) &&
skip_prefix(line, "ERR ", &line)) {
die("remote error: %s", line);
}
/* otherwise, just report the write error */
die("%s", msg);
}
The tricky thing is that the writer does not always know the correct fd
to read more packets from (since the write errors may be deep in generic
code). I suspect we could rig up some kind of hacky global "if this
descriptor variable is non-negative, then do a last ditch read from it".
I do wonder if the race is better or worse when doing local fetches in
the test suite. On a real network with actual transit times, I suspect
we'd do better, because our writes would still be fast (we dump bytes to
the OS buffer) and we'd spend a higher percentage of our time waiting to
read back from the other side (which is what we want, because then we
see the ERR they wrote to us). That's just a guess, though.
> The fix obviously looks good. Thanks.
Yeah, I don't think any of the above discussion needs to block the fix
here.
Here's a re-roll of the first patch, though, marked for translation as
requested by Duy.
-- >8 --
Subject: [PATCH] fetch: avoid calling write_or_die()
The write_or_die() function has one quirk that a caller might not
expect: when it sees EPIPE from the write() call, it translates that
into a death by SIGPIPE. This doesn't change the overall behavior (the
program exits either way), but it does potentially confuse test scripts
looking for a non-signal exit code.
Let's switch away from using write_or_die() in a few code paths, which
will give us more consistent exit codes. It also gives us the
opportunity to write more descriptive error messages, since we have
context that write_or_die() does not.
Note that this won't do much by itself, since we'd typically be killed
by SIGPIPE before write_or_die() even gets a chance to do its thing.
That will be addressed in the next patch.
Signed-off-by: Jeff King <peff@peff.net>
---
fetch-pack.c | 9 ++++++---
pkt-line.c | 6 ++++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 812be15d7e..e69993b2eb 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -191,8 +191,10 @@ static void send_request(struct fetch_pack_args *args,
if (args->stateless_rpc) {
send_sideband(fd, -1, buf->buf, buf->len, LARGE_PACKET_MAX);
packet_flush(fd);
- } else
- write_or_die(fd, buf->buf, buf->len);
+ } else {
+ if (write_in_full(fd, buf->buf, buf->len) < 0)
+ die_errno(_("unable to write to remote"));
+ }
}
static void insert_one_alternate_object(struct fetch_negotiator *negotiator,
@@ -1163,7 +1165,8 @@ static int send_fetch_request(struct fetch_negotiator *negotiator, int fd_out,
/* Send request */
packet_buf_flush(&req_buf);
- write_or_die(fd_out, req_buf.buf, req_buf.len);
+ if (write_in_full(fd_out, req_buf.buf, req_buf.len) < 0)
+ die_errno(_("unable to write request to remote"));
strbuf_release(&req_buf);
return ret;
diff --git a/pkt-line.c b/pkt-line.c
index d4b71d3e82..6bd496a9bb 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -88,13 +88,15 @@ static void packet_trace(const char *buf, unsigned int len, int write)
void packet_flush(int fd)
{
packet_trace("0000", 4, 1);
- write_or_die(fd, "0000", 4);
+ if (write_in_full(fd, "0000", 4) < 0)
+ die_errno(_("unable to write flush packet"));
}
void packet_delim(int fd)
{
packet_trace("0001", 4, 1);
- write_or_die(fd, "0001", 4);
+ if (write_in_full(fd, "0001", 4) < 0)
+ die_errno(_("unable to write delim packet"));
}
int packet_flush_gently(int fd)
--
2.21.0.684.gc9dc8b89c9
next prev parent reply other threads:[~2019-03-05 4:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-06 15:11 t5570-git-daemon fails with SIGPIPE on OSX SZEDER Gábor
2018-08-06 15:31 ` SZEDER Gábor
2019-02-08 8:32 ` Johannes Schindelin
2019-02-08 12:54 ` SZEDER Gábor
2018-08-14 22:32 ` Jeff King
2018-08-14 22:37 ` Jeff King
2019-02-08 9:02 ` Johannes Schindelin
2019-02-08 9:28 ` Johannes Schindelin
2019-02-08 19:54 ` Jeff King
2019-03-01 15:02 ` Johannes Schindelin
2019-03-01 19:00 ` Jeff King
2019-03-02 21:21 ` Johannes Schindelin
2019-03-03 16:54 ` Jeff King
2019-03-03 16:55 ` [PATCH 1/2] fetch: avoid calling write_or_die() Jeff King
2019-03-04 13:42 ` Duy Nguyen
2019-03-05 4:11 ` Jeff King
2019-03-03 16:58 ` [PATCH 2/2] fetch: ignore SIGPIPE during network operation Jeff King
2019-03-04 1:11 ` Junio C Hamano
2019-03-05 4:11 ` Jeff King [this message]
2019-03-03 1:21 ` t5570-git-daemon fails with SIGPIPE on OSX Junio C Hamano
2019-03-03 14:56 ` Johannes Schindelin
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190305041139.GA19800@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=drizzd@gmx.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=szeder.dev@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).