All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH v2 3/3] sideband: add defense against packets missing a band designator
Date: Fri, 23 Oct 2020 07:36:25 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2010230732250.56@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20201023084827.GE4012156@coredump.intra.peff.net>

Hi Peff,

On Fri, 23 Oct 2020, Jeff King wrote:

> On Mon, Oct 19, 2020 at 07:35:42PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > diff --git a/pkt-line.c b/pkt-line.c
> > index 657a702927..f72048f623 100644
> > --- a/pkt-line.c
> > +++ b/pkt-line.c
> > @@ -461,8 +461,10 @@ int recv_sideband(const char *me, int in_stream, int out)
> >  	enum sideband_type sideband_type;
> >
> >  	while (1) {
> > -		len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX,
> > -				  0);
> > +		int status = packet_read_with_status(in_stream, NULL, NULL, buf,
> > +						     LARGE_PACKET_MAX, &len, 0);
> > +		if (!len && status == PACKET_READ_NORMAL)
> > +			BUG("missing band designator");
> >  		if (!demultiplex_sideband(me, buf, len, 0, &scratch,
> >  					  &sideband_type))
>
> I also wonder if this status-check should be pushed down into
> demultiplex_sideband() by passing "status",

I tried that, but as mentioned in the commit message, fbd76cd450
(sideband: reverse its dependency on pkt-line, 2019-01-16) went out of its
way to _stop_ the code inside `demultiplex_sideband()` from relying on
anything in `pkt-line.h`. And that `PACKET_READ_NORMAL` and
`PACKET_READ_EOF` _is_ from `pkt-line.h`.

Ciao,
Dscho

> for two reasons:
>
>   1. So we don't have to repeat it (though it isn't that big)
>
>   2. The other half of this weirdness is that if we get an early EOF,
>      we'll hit the "missing sideband designator" die() message. But
>      that's not really what happened; we probably got a network hangup.
>      And we could distinguish that case by checking for status ==
>      PACKET_READ_EOF and provide a better message.
>
> Something like this (completely untested):
>
> diff --git a/sideband.c b/sideband.c
> index 0a60662fa6..6ad15ed581 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -115,6 +115,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
>  #define DUMB_SUFFIX "        "
>
>  int demultiplex_sideband(const char *me, char *buf, int len,
> +			 enum packet_read_status status,
>  			 int die_on_error,
>  			 struct strbuf *scratch,
>  			 enum sideband_type *sideband_type)
> @@ -130,17 +131,29 @@ int demultiplex_sideband(const char *me, char *buf, int len,
>  			suffix = DUMB_SUFFIX;
>  	}
>
> -	if (len == 0) {
> -		*sideband_type = SIDEBAND_FLUSH;
> -		goto cleanup;
> -	}
> -	if (len < 1) {
> +	if (status == PACKET_READ_EOF) {
>  		strbuf_addf(scratch,
> -			    "%s%s: protocol error: no band designator",
> +			    "%s%s: protocol error: eof while reading packet",
>  			    scratch->len ? "\n" : "", me);
>  		*sideband_type = SIDEBAND_PROTOCOL_ERROR;
>  		goto cleanup;
>  	}
> +
> +	if (len < 0)
> +		BUG("negative length on non-eof packet read");
> +
> +	if (len == 0) {
> +		if (status == PACKET_READ_NORMAL) {
> +			strbuf_addf(scratch,
> +				    "%s%s protocol error: no band designator",
> +				    scratch->len ? "\n" : "", me);
> +			*sideband_type = SIDEBAND_PROTOCOL_ERROR;
> +		} else {
> +			*sideband_type = SIDEBAND_FLUSH;
> +		}
> +		goto cleanup;
> +	}
> +
>  	band = buf[0] & 0xff;
>  	buf[len] = '\0';
>  	len--;
>

  reply	other threads:[~2020-10-23 12:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 14:45 [PATCH] t5500.43: make the check a bit more robust Johannes Schindelin via GitGitGadget
2020-10-13 17:53 ` Junio C Hamano
2020-10-13 18:55 ` Jeff King
2020-10-13 19:07   ` Junio C Hamano
2020-10-13 19:09   ` Jeff King
2020-10-17  3:31     ` Johannes Schindelin
2020-10-17  2:34   ` Johannes Schindelin
2020-10-19 19:35 ` [PATCH v2 0/3] Work around flakiness in t5500.43 Johannes Schindelin via GitGitGadget
2020-10-19 19:35   ` [PATCH v2 1/3] sideband: avoid reporting incomplete sideband messages Johannes Schindelin via GitGitGadget
2020-10-20 20:33     ` Junio C Hamano
2020-10-20 20:48       ` Johannes Schindelin
2020-10-20 21:33         ` Junio C Hamano
2020-10-19 19:35   ` [PATCH v2 2/3] sideband: report unhandled incomplete sideband messages as bugs Johannes Schindelin via GitGitGadget
2020-10-19 19:35   ` [PATCH v2 3/3] sideband: add defense against packets missing a band designator Johannes Schindelin via GitGitGadget
2020-10-20 20:36     ` Junio C Hamano
2020-10-23  8:34     ` Jeff King
2020-10-23 14:44       ` Junio C Hamano
2020-10-23  8:48     ` Jeff King
2020-10-23  5:36       ` Johannes Schindelin [this message]
2020-10-23  8:50   ` [PATCH v2 0/3] Work around flakiness in t5500.43 Jeff King
2020-10-26 16:04     ` Johannes Schindelin
2020-10-26 16:09   ` [PATCH v3 0/2] " Johannes Schindelin via GitGitGadget
2020-10-26 16:09     ` [PATCH v3 1/2] sideband: avoid reporting incomplete sideband messages Johannes Schindelin via GitGitGadget
2020-10-26 16:09     ` [PATCH v3 2/2] sideband: report unhandled incomplete sideband messages as bugs Johannes Schindelin via GitGitGadget
2020-10-26 18:33     ` [PATCH v3 0/2] Work around flakiness in t5500.43 Junio C Hamano
2020-10-27  6:52     ` [PATCH] sideband: diagnose more incoming packet anomalies Jeff King
2020-10-27  7:12       ` Jeff King
2020-10-27 18:56         ` Junio C Hamano
2020-10-27 20:42           ` Jeff King
2020-10-27 21:38             ` Junio C Hamano
2020-10-28  9:33               ` Jeff King
2020-10-27  7:13       ` Jeff King
2020-10-27 19:04         ` Junio C Hamano

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=nycvar.QRO.7.76.6.2010230732250.56@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.com \
    --cc=peff@peff.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 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.