From: Lorenzo Pegorari <lorenzo.pegorari2002@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
Junio C Hamano <gitster@pobox.com>,
Patrick Steinhardt <ps@pks.im>, fox <fox.gbr@townlong-yak.com>
Subject: Re: [PATCH v2] http: fix memory leak in fetch_and_setup_pack_index()
Date: Mon, 1 Jun 2026 15:27:53 +0200 [thread overview]
Message-ID: <ah2I2b345uU6LKJI@lorenzo-VM> (raw)
In-Reply-To: <20260529053659.GC1099450@coredump.intra.peff.net>
On Fri, May 29, 2026 at 01:36:59AM -0400, Jeff King wrote:
> On Fri, May 29, 2026 at 01:49:44AM +0200, LorenzoPegorari wrote:
>
> > Inside the function `fetch_and_setup_pack_index()`, when the pack
> > obtained using `parse_pack_index()` fails to be verified by
> > `verify_pack_index()`, the function returns without closing and freeing
> > said pack.
> >
> > Fix this by calling `close_pack_index()` to munmap the index file for
> > the leaking pack (which might have been mmapped by `fetch_pack_index()`
> > or `verify_pack_index()`), and then free it, when the verification
> > fails.
> >
> > Also, do some more cleanup by removing the useless call to the function
> > `unlink()`. This is not necessary anymore since 63aca3f7f1 (dumb-http:
> > store downloaded pack idx as tempfile, 2024-10-25), when
> > `fetch_pack_index()` started registering its return value (in this case
> > `tmp_idx`) as a tempfile to be deleted at process exit.
>
> I think the patch as-is is OK. But when I see this kind of "also, do
> this..." in a commit message it is a good time to consider whether that
> should happen in a separate patch.
>
> Here it does not make sense to remove the unlink() afterwards; you'd
> wonder why it was not present in the cleanup added by your patch.
>
> But it _could_ be done as a preparatory patch. And the rationale for
> doing that on its own I think is roughly:
>
> 1. It is mostly doing nothing, because 63aca3f7f1 registered it as a
> tempfile, so it will be cleaned up at process end anyway (whether
> we succeed in fetching it or not).
>
> 2. It is maybe a little harmful, because we are going to unlink() it
> now, and then later the tempfile code will try to unlink() it again
> (so a simultaneous fetch could have created the same file).
>
> For something this small, though, I am OK just lumping it together.
> There are diminishing returns from polishing it further.
Yeah, this makes sense. I will separate it in 2 different patches.
> -Peff
Thanks,
Lorenzo
next prev parent reply other threads:[~2026-06-01 13:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 14:54 [PATCH] http: fix memory leak in fetch_and_setup_pack_index() LorenzoPegorari
2026-05-19 19:17 ` Jeff King
2026-05-28 1:22 ` Lorenzo Pegorari
2026-05-29 5:32 ` Jeff King
2026-05-28 23:49 ` [PATCH v2] " LorenzoPegorari
2026-05-29 5:36 ` Jeff King
2026-05-29 5:40 ` Jeff King
2026-06-01 13:34 ` Lorenzo Pegorari
2026-06-01 13:27 ` Lorenzo Pegorari [this message]
2026-06-01 13:51 ` [PATCH v3 0/2] " LorenzoPegorari
2026-06-01 13:52 ` [PATCH v3 1/2] http: cleanup function fetch_and_setup_pack_index() LorenzoPegorari
2026-06-01 13:52 ` [PATCH v3 2/2] http: fix memory leak in fetch_and_setup_pack_index() LorenzoPegorari
2026-06-02 6:24 ` [PATCH v3 0/2] " Jeff King
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=ah2I2b345uU6LKJI@lorenzo-VM \
--to=lorenzo.pegorari2002@gmail.com \
--cc=fox.gbr@townlong-yak.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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.