git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
	Kyle Lippincott <spectral@google.com>,
	Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v2 0/3] midx: various brown paper bag fixes
Date: Tue, 11 Jun 2024 13:31:20 -0400	[thread overview]
Message-ID: <ZmiJ6H6xkvc5WnC9@nand.local> (raw)
In-Reply-To: <cover.1718126886.git.me@ttaylorr.com>

On Tue, Jun 11, 2024 at 01:28:07PM -0400, Taylor Blau wrote:
> This series fixes a couple of brown paper bag bugs in the MIDX/bitmap
> code.
>
> This version is basically identical to the previous round, except that
> we use the sentinel value "-1" as the 'pack_int_id' when reusing from a
> single (non-MIDX'd) pack. This is a "garbage in, garbage out" measure to
> ensure that we notice any regressions here loudly.
>
> Thanks in advance for your review!

I must have forgotten to tag my original "v2" as such, since my scripts
decided that this is actually v2. Apologies for any confusion, this
latest version is certainly v3, the range-diff looks like so:

--- 8< ---

1:  c62daacd1d = 1:  0bdf925366 midx-write.c: do not read existing MIDX with `packs_to_include`
2:  9b78fa2923 ! 2:  4b006f44a5 pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse
    @@ Commit message

         Avoid the uninitialized read by ensuring that the pack_int_id field is
         set in the single-pack reuse case by setting it to either the MIDX
    -    preferred pack's pack_int_id, or '0', in the case of single-pack
    +    preferred pack's pack_int_id, or '-1', in the case of single-pack
         bitmaps.  In the latter case, we never read the pack_int_id field, so
    -    the choice of '0' is arbitrary.
    +    the choice of '-1' is intentional as a "garbage in, garbage out"
    +    measure.

         Guard against further regressions in this area by adding a test which
         ensures that we do not throw out deltas from the preferred pack as
    @@ pack-bitmap.c: void reuse_partial_packfile_from_bitmap(struct bitmap_index *bitm
     +			 * process the pack via try_partial_reuse(), we won't
     +			 * use the `pack_int_id` field since we have a non-MIDX
     +			 * bitmap.
    ++			 *
    ++			 * Use '-1' as a sentinel value to make it clear
    ++			 * that we do not expect to read this field.
     +			 */
    -+			pack_int_id = 0;
    ++			pack_int_id = -1;
      		}

      		ALLOC_GROW(packs, packs_nr + 1, packs_alloc);
3:  e08f679dec = 3:  06de4005f1 pack-revindex.c: guard against out-of-bounds pack lookups

--- >8 ---

Thanks,
Taylor

      parent reply	other threads:[~2024-06-11 17:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09 15:27 [PATCH] pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse Taylor Blau
2024-06-10  5:55 ` Patrick Steinhardt
2024-06-10 14:57   ` Taylor Blau
2024-06-11  8:12     ` Patrick Steinhardt
2024-06-10 20:10 ` [PATCH v2 0/3] midx: various brown paper bag fixes Taylor Blau
2024-06-10 20:10   ` [PATCH v2 1/3] midx-write.c: do not read existing MIDX with `packs_to_include` Taylor Blau
2024-06-10 20:10   ` [PATCH v2 2/3] pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse Taylor Blau
2024-06-11  9:11     ` Jeff King
2024-06-11 17:03       ` Junio C Hamano
2024-06-10 20:10   ` [PATCH v2 3/3] pack-revindex.c: guard against out-of-bounds pack lookups Taylor Blau
2024-06-11 17:28 ` [PATCH v2 0/3] midx: various brown paper bag fixes Taylor Blau
2024-06-11 17:28   ` [PATCH v2 1/3] midx-write.c: do not read existing MIDX with `packs_to_include` Taylor Blau
2024-06-11 17:28   ` [PATCH v2 2/3] pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse Taylor Blau
2024-06-11 17:28   ` [PATCH v2 3/3] pack-revindex.c: guard against out-of-bounds pack lookups Taylor Blau
2024-06-11 17:31   ` Taylor Blau [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=ZmiJ6H6xkvc5WnC9@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=spectral@google.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).