git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCHv2 04/10] pkt-line: change error message for oversized packet
Date: Mon, 18 Feb 2013 04:49:59 -0500	[thread overview]
Message-ID: <20130218094959.GA16408@sigill.intra.peff.net> (raw)
In-Reply-To: <7vd2vyarjy.fsf@alter.siamese.dyndns.org>

On Mon, Feb 18, 2013 at 01:40:17AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I'm really tempted to bump all of our 1000-byte buffers to just use
> > LARGE_PACKET_MAX. If we provided a packet_read variant that used a
> > static buffer (which is fine for all but one or two callers), then it
> > would not take much memory...
> 
> I thought that 1000-byte limit was kept when we introduced the 64k
> interface to interoperate with other side that does not yet support
> the 64k interface. Is your justification that such an old version of
> Git no longer matters in the real world (which is true, I think), or
> we use 1000-byte limit in some codepaths even when we know that we
> are talking with a 64k-capable version of Git on the other side?

I should have been more clear that I want to bump only the _reading_
side, not the writing.

The sideband-64k capability bumps the sideband chunk size. But the size
for packetized ref advertisement lines has remained at 1000. Which it
must, since we start outputting them before doing capability
negotiation. The sender will die before writing a longer ref line (see
pkg-line.c:format_packet), and most of the reading callsites feed a
1000-byte buffer to packet_read_line (which will die if we get a larger
packet). So the upgrade path for that would be:

  1. Git bumps up all reading buffers to LARGE_PACKET_MAX, just in case.
     This immediately covers us for any alternate implementations that
     send larger ref packets (I do not know if any exist, but the
     documentation does not mention this limitation at all, so I would
     not be surprised if other implementations just use LARGE_PACKET_MAX
     as a maximum).

  2. Many years pass. We decide that Git v1.8.2 and older are ancient
     history and not worth caring about.

  3. We bump the 1000-byte limit for format_packet to LARGE_PACKET_MAX.

This is not pressing at all; I wouldn't have even noticed it if I hadn't
been wondering how large to make the new buffer I was adding in a later
patch. I have not heard of anyone running up against this limit in
practice. But it's easy to do (1), and it starts the clock ticking for
the 1000-byte readers to become obsolete.

-Peff

  reply	other threads:[~2013-02-18  9:50 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-16  6:44 [PATCH 0/3] make smart-http more robust against bogus server input Jeff King
2013-02-16  6:46 ` [PATCH 1/3] pkt-line: teach packet_get_line a no-op mode Jeff King
2013-02-17 10:41   ` Jonathan Nieder
2013-02-16  6:47 ` [PATCH 2/3] remote-curl: verify smart-http metadata lines Jeff King
2013-02-17 10:49   ` Jonathan Nieder
2013-02-17 19:14     ` Jeff King
2013-02-18  0:54       ` Jonathan Nieder
2013-02-18  8:59         ` Jeff King
2013-02-16  6:49 ` [PATCH 3/3] remote-curl: sanity check ref advertisement from server Jeff King
2013-02-17 11:05   ` Jonathan Nieder
2013-02-17 19:28     ` Jeff King
2013-02-18  1:41       ` Jonathan Nieder
2013-02-18  9:12         ` [PATCHv2 0/10] pkt-line and remote-curl cleanups server Jeff King
2013-02-18  9:14           ` [PATCHv2 01/10] pkt-line: move a misplaced comment Jeff King
2013-02-18  9:15           ` [PATCHv2 02/10] pkt-line: drop safe_write function Jeff King
2013-02-18  9:56             ` Jonathan Nieder
2013-02-18 10:24               ` Jeff King
2013-02-18  9:16           ` [PATCHv2 03/10] pkt-line: clean up "gentle" reading function Jeff King
2013-02-18 10:12             ` Jonathan Nieder
2013-02-18 10:25               ` Jeff King
2013-02-18  9:22           ` [PATCHv2 04/10] pkt-line: change error message for oversized packet Jeff King
2013-02-18  9:40             ` Junio C Hamano
2013-02-18  9:49               ` Jeff King [this message]
2013-02-18 21:25                 ` Junio C Hamano
2013-02-18 21:33                   ` Jeff King
2013-02-20  8:47                     ` Jeff King
2013-02-20  8:54                       ` Junio C Hamano
2013-02-18 10:15             ` Jonathan Nieder
2013-02-18 10:26               ` Jeff King
2013-02-18  9:22           ` [PATCHv2 05/10] pkt-line: rename s/packet_read_line/packet_read/ Jeff King
2013-02-18 10:19             ` Jonathan Nieder
2013-02-18 10:29               ` Jeff King
2013-02-18 11:05                 ` Jonathan Nieder
2013-02-18  9:26           ` [PATCHv2 06/10] pkt-line: share buffer/descriptor reading implementation Jeff King
2013-02-18 10:43             ` Jonathan Nieder
2013-02-18 10:48               ` Jeff King
2013-02-18 10:54                 ` Jonathan Nieder
2013-02-18  9:27           ` [PATCHv2 07/10] teach get_remote_heads to read from a memory buffer Jeff King
2013-02-18  9:29           ` [PATCHv2 08/10] remote-curl: pass buffer straight to get_remote_heads Jeff King
2013-02-18 10:47             ` Jonathan Nieder
2013-02-18  9:29           ` [PATCHv2 0/10] pkt-line and remote-curl cleanups server Junio C Hamano
2013-02-18  9:33             ` Jeff King
2013-02-18  9:49               ` Junio C Hamano
2013-02-18  9:55                 ` Jeff King
2013-02-20  7:14                 ` Shawn Pearce
2013-02-18  9:29           ` [PATCHv2 09/10] remote-curl: move ref-parsing code up in file Jeff King
2013-02-18  9:30           ` [PATCHv2 10/10] remote-curl: always parse incoming refs Jeff King
2013-02-18 10:50             ` Jonathan Nieder
2013-02-20  7:41               ` Shawn Pearce
2013-02-20  7:05           ` [PATCHv2 0/10] pkt-line and remote-curl cleanups server Shawn Pearce

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=20130218094959.GA16408@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=spearce@spearce.org \
    /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 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 NNTP newsgroup(s).