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
next prev parent 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).