All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] sideband: diagnose more incoming packet anomalies
Date: Tue, 27 Oct 2020 14:38:12 -0700	[thread overview]
Message-ID: <xmqqzh479wor.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20201027204205.GA643357@coredump.intra.peff.net> (Jeff King's message of "Tue, 27 Oct 2020 16:42:05 -0400")

Jeff King <peff@peff.net> writes:

> Does this patch seem otherwise worth doing?

Yeah.

FWIW, I do not find the "dependency" thing disturbing.  sideband is
an extension of the pkt-line mechansim, so it is natural that it
depends on pkt-line.  I'd also be happy if enums, structures and
calls defined in both headers are made available by just including
one of them (e.g. retire sideband.h, perhaps).

> An alternate patch would be to keep the behavior the same and just
> clarify the code a bit. Something like:

This also looks OK to me from readability's point of view, but it
does not as much help the end user who is puzzled as the real thing,
I am afraid.

Thanks.

> -- >8 --
> Subject: [PATCH] demultiplex_sideband(): clarify corner cases
>
> The size checks in demultiplex_sideband() are a bit subtle and
> confusing:
>
>   - we consider a zero-length packet ("0004") to be a flush packet, even
>     though it's not really one. This is perhaps wrong, but it should
>     never happen in our protocol, and we err on the side of history and
>     leniency. We'll leave a comment indicating that we expect this case.
>
>   - likewise we consider any flush-like packet (e.g., "0001" delim) to
>     be a flush. I didn't confirm whether this is necessary for normal
>     protocol usage. It may be for the everything-over-sideband mode
>     introduced by 0bbc0bc574 ({fetch,upload}-pack: sideband v2 fetch
>     response, 2019-01-16). Likewise let's leave a comment.
>
>   - we check for "len < 1" to see if there's no sideband designator.
>     That's confusing, because we already covered the "len == 0" case.
>     What is interesting is the "len < 0" case. But that's not a missing
>     sideband designator, but rather an error or EOF from the pkt-line
>     code. This should never happen, though, because our callers instruct
>     pkt-line to die() on EOF anyway. So let's make it more obvious
>     that we're looking for a negative value here, and consider it a
>     BUG() in the caller to pass us garbage.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  sideband.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/sideband.c b/sideband.c
> index 0a60662fa6..6ba1925614 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -130,17 +130,18 @@ int demultiplex_sideband(const char *me, char *buf, int len,
>  			suffix = DUMB_SUFFIX;
>  	}
>  
> +	if (len < 0)
> +		BUG("error/eof packet passed to demultiplex_sideband");
> +
>  	if (len == 0) {
> +		/*
> +		 * we treat all flush-like packets (flush, delim, etc) and even
> +		 * empty data packets as a flush
> +		 */
>  		*sideband_type = SIDEBAND_FLUSH;
>  		goto cleanup;
>  	}
> -	if (len < 1) {
> -		strbuf_addf(scratch,
> -			    "%s%s: protocol error: no band designator",
> -			    scratch->len ? "\n" : "", me);
> -		*sideband_type = SIDEBAND_PROTOCOL_ERROR;
> -		goto cleanup;
> -	}
> +
>  	band = buf[0] & 0xff;
>  	buf[len] = '\0';
>  	len--;

  reply	other threads:[~2020-10-27 21:38 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
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 [this message]
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=xmqqzh479wor.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=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.