From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Benjamin Flesch <benjaminflesch@icloud.com>
Subject: Re: [PATCH 0/9] bound upload-pack memory allocations
Date: Wed, 28 Feb 2024 14:47:43 -0800 [thread overview]
Message-ID: <xmqqa5nkjje8.fsf@gitster.g> (raw)
In-Reply-To: <20240228223700.GA1157826@coredump.intra.peff.net> (Jeff King's message of "Wed, 28 Feb 2024 17:37:00 -0500")
Jeff King <peff@peff.net> writes:
> We're not doing a coordinated disclosure or special release for this.
> Even after these patches, it's possible to get upload-pack to allocate
> quite a bit of memory, especially for a large repository. Not to mention
> that pack-objects may also allocate quite a bit to serve the pack
> itself. So while this is low-hanging fruit, a public-facing Git site
> probably still needs to have some kind of external tooling to kill
> hungry processes (even if it's just OOM-killing them so they don't hurt
> other clients).
>
> [1/9]: upload-pack: drop separate v2 "haves" array
> [2/9]: upload-pack: switch deepen-not list to an oid_array
> [3/9]: upload-pack: use oidset for deepen_not list
> [4/9]: upload-pack: use a strmap for want-ref lines
> [5/9]: upload-pack: accept only a single packfile-uri line
> [6/9]: upload-pack: disallow object-info capability by default
> [7/9]: upload-pack: always turn off save_commit_buffer
> [8/9]: upload-pack: use PARSE_OBJECT_SKIP_HASH_CHECK in more places
> [9/9]: upload-pack: free tree buffers after parsing
I saw them when they were posted to the security list and they
looked good already. Will queue. Thanks.
prev parent reply other threads:[~2024-02-28 22:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 22:37 [PATCH 0/9] bound upload-pack memory allocations Jeff King
2024-02-28 22:37 ` [PATCH 1/9] upload-pack: drop separate v2 "haves" array Jeff King
2024-02-28 22:37 ` [PATCH 2/9] upload-pack: switch deepen-not list to an oid_array Jeff King
2024-02-28 22:37 ` [PATCH 3/9] upload-pack: use oidset for deepen_not list Jeff King
2024-02-28 22:38 ` [PATCH 4/9] upload-pack: use a strmap for want-ref lines Jeff King
2024-02-28 22:38 ` [PATCH 5/9] upload-pack: accept only a single packfile-uri line Jeff King
2024-02-28 22:38 ` [PATCH 6/9] upload-pack: disallow object-info capability by default Jeff King
2024-03-04 8:34 ` Patrick Steinhardt
2024-03-04 9:59 ` Jeff King
2024-04-29 20:49 ` Taylor Blau
2024-02-28 22:39 ` [PATCH 7/9] upload-pack: always turn off save_commit_buffer Jeff King
2024-02-28 22:39 ` [PATCH 8/9] upload-pack: use PARSE_OBJECT_SKIP_HASH_CHECK in more places Jeff King
2024-02-28 22:39 ` [PATCH 9/9] upload-pack: free tree buffers after parsing Jeff King
2024-03-04 8:33 ` Patrick Steinhardt
2024-03-04 9:57 ` Jeff King
2024-03-04 10:00 ` Patrick Steinhardt
2024-02-28 22:47 ` Junio C Hamano [this message]
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=xmqqa5nkjje8.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=benjaminflesch@icloud.com \
--cc=git@vger.kernel.org \
--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.