git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/3] midx: various brown paper bag fixes

From
Taylor Blau <me@ttaylorr.com>
Date
Jun 11, 2024, 17:31 UTC
Message-ID
<ZmiJ6H6xkvc5WnC9@nand.local>
In-Reply-To
<cover.1718126886.git.me@ttaylorr.com>
On Tue, Jun 11, 2024 at 01:28:07PM -0400, Taylor Blau wrote:
Show 9 quoted lines
> 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

Previous: Taylor Blau
Message 15 of 15 in “pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse”
  1. pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 9, 2024
  2. Patrick SteinhardtJun 10, 2024
  3. Taylor BlauJun 10, 2024
  4. Patrick SteinhardtJun 11, 2024
  5. 0/3 midx: various brown paper bag fixesTaylor Blau, Jun 10, 2024
  6. 1/3 midx-write.c: do not read existing MIDX with `packs_to_include`Taylor Blau, Jun 10, 2024
  7. 2/3 pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 10, 2024
  8. Jeff KingJun 11, 2024
  9. Junio C HamanoJun 11, 2024
  10. 3/3 pack-revindex.c: guard against out-of-bounds pack lookupsTaylor Blau, Jun 10, 2024
  11. 0/3 midx: various brown paper bag fixesTaylor Blau, Jun 11, 2024
  12. 1/3 midx-write.c: do not read existing MIDX with `packs_to_include`Taylor Blau, Jun 11, 2024
  13. 2/3 pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 11, 2024
  14. 3/3 pack-revindex.c: guard against out-of-bounds pack lookupsTaylor Blau, Jun 11, 2024
  15. Taylor BlauJun 11, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.