git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] repack: free geometry struct
Date: Tue, 8 Aug 2023 17:17:59 -0400	[thread overview]
Message-ID: <20230808211759.GA322409@coredump.intra.peff.net> (raw)
In-Reply-To: <ZNKer8BfwaKEeV+W@nand.local>

On Tue, Aug 08, 2023 at 03:59:43PM -0400, Taylor Blau wrote:

> > I did actually put together the "put it on the stack" patch, which swaps
> > out:
> >
> >   if (geometry)
> >
> > for:
> >
> >   if (geometric_factor)
> >
> > to get around the NULL checks. But besides being noisy for little gain,
> > it ends up with some subtle gotchas, because we pass "&geometry" into
> > some functions which don't have access to "geometric_factor" (so now
> > extra call-sites have to keep track of "is this struct valid enough to
> > pass").
> 
> ...I think that storing the geometric_factor value on the pack_geometry
> struct itself gets around most of these issues.
> 
> This version is still somewhat noisy, but it's not too bad IMHO. I'm
> fine with either your approach or mine :-).

Yeah, that is much better than what I had put together, as it means that
pack_geometry is always in a consistent state, even if we didn't call
init_pack_geometry(). So it is safe to clear() it, for example, without
checking geometric_factor again. And any sub-functions can likewise
check whether it contains any useful data. So you'd need this fixup on
top of your patch:

diff --git a/builtin/repack.c b/builtin/repack.c
index 13e4f0094e..80bffc36d4 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -579,7 +579,7 @@ static void midx_included_packs(struct string_list *include,
 		string_list_insert(include, xstrfmt("%s.idx", item->string));
 	for_each_string_list_item(item, names)
 		string_list_insert(include, xstrfmt("pack-%s.idx", item->string));
-	if (geometry) {
+	if (geometry->split_factor) {
 		struct strbuf buf = STRBUF_INIT;
 		uint32_t i;
 		for (i = geometry->split; i < geometry->pack_nr; i++) {

or else t5326 (and I think a few others) will fail.

I'd be happy to proceed that way if you want to clean it up with a
commit message, but I think we should do it on top of the leak-fix (I
wanted to say that the heap-to-stack conversion was low-risk, but both
of us introduced bugs while trying it ;) ).

-Peff

  reply	other threads:[~2023-08-08 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 18:50 [PATCH] repack: free geometry struct Jeff King
2023-08-08 19:59 ` Taylor Blau
2023-08-08 21:17   ` Jeff King [this message]
2023-08-09 20:32     ` [PATCH 0/2] repack: prevent geometry struct leak Taylor Blau
2023-08-09 20:32       ` [PATCH 1/2] repack: free geometry struct Taylor Blau
2023-08-09 20:32       ` [PATCH 2/2] repack: move `pack_geometry` struct to the stack Taylor Blau
2023-08-10  0:19       ` [PATCH 0/2] repack: prevent geometry struct leak 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=20230808211759.GA322409@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    /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).