From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Johannes.Schindelin@gmx.de,
chakrabortyabhradeep79@gmail.com, derrickstolee@github.com,
jonathantanmy@google.com, kaartic.sivaraam@gmail.com
Subject: [PATCH v2 0/7] midx: permit changing the preferred pack when reusing the MIDX
Date: Mon, 22 Aug 2022 15:50:24 -0400 [thread overview]
Message-ID: <cover.1661197803.git.me@ttaylorr.com> (raw)
In-Reply-To: <cover.1660944574.git.me@ttaylorr.com>
Here is a small reroll of my series that resolves a bug that was
reported[1] by Johannes, and investigated by him, Abhradeep, and Stolee
in that same sub-thread.
As before: the crux of the issue is that a MIDX bitmap can enter a
corrupt state when changing the preferred pack from its value in an
existing MIDX in certain circumstances as described in the first and
final patches.
This version incorporates some cosmetic changes suggested by Stolee, and
adds a new patch on top which avoids adding objects from the MIDX that
were represented by the (new) preferred pack, since we know we'll end up
discarding those objects anyways. For convenience, a range-diff against
v1 is included below.
Thanks again for your review!
[1]: https://lore.kernel.org/git/p3r70610-8n52-s8q0-n641-onp4ps01330n@tzk.qr/
Taylor Blau (7):
t5326: demonstrate potential bitmap corruption
t/lib-bitmap.sh: avoid silencing stderr
midx.c: extract `struct midx_fanout`
midx.c: extract `midx_fanout_add_midx_fanout()`
midx.c: extract `midx_fanout_add_pack_fanout()`
midx.c: include preferred pack correctly with existing MIDX
midx.c: avoid adding preferred objects twice
midx.c | 139 +++++++++++++++++++++++-----------
t/lib-bitmap.sh | 2 +-
t/t5326-multi-pack-bitmaps.sh | 44 +++++++++++
3 files changed, 139 insertions(+), 46 deletions(-)
Range-diff against v1:
1: 3e30ab1a19 ! 1: 6b38bfcd2c t5326: demonstrate potential bitmap corruption
@@ t/t5326-multi-pack-bitmaps.sh: test_expect_success 'graceful fallback when missi
'
+test_expect_success 'preferred pack change with existing MIDX bitmap' '
-+ rm -fr repo &&
-+ git init repo &&
-+ test_when_finished "rm -fr repo" &&
++ git init preferred-pack-with-existing &&
+ (
-+ cd repo &&
++ cd preferred-pack-with-existing &&
+
+ test_commit base &&
+ test_commit other &&
@@ t/t5326-multi-pack-bitmaps.sh: test_expect_success 'graceful fallback when missi
+ p2="$(git pack-objects "$objdir/pack/pack" \
+ --delta-base-offset <p2.objects)" &&
+
-+ # Generate a MIDX containing the first two packs, marking p1 as
-+ # preferred, and ensure that it can be successfully cloned.
++ # Generate a MIDX containing the first two packs,
++ # marking p1 as preferred, and ensure that it can be
++ # successfully cloned.
+ git multi-pack-index write --bitmap \
+ --preferred-pack="pack-$p1.pack" &&
+ test_path_is_file $midx &&
+ test_path_is_file $midx-$(midx_checksum $objdir).bitmap &&
+ git clone --no-local . clone1 &&
+
-+ # Then generate a new pack which sorts ahead of any existing
-+ # pack (by tweaking the pack prefix).
++ # Then generate a new pack which sorts ahead of any
++ # existing pack (by tweaking the pack prefix).
+ test_commit foo &&
+ git pack-objects --all --unpacked $objdir/pack/pack0 &&
+
-+ # Generate a new MIDX which changes the preferred pack to a pack
-+ # contained in the existing MIDX, such that not all objects from
-+ # p2 that appear in the MIDX had their copy selected from p2.
++ # Generate a new MIDX which changes the preferred pack
++ # to a pack contained in the existing MIDX, such that
++ # not all objects from p2 that appear in the MIDX had
++ # their copy selected from p2.
+ git multi-pack-index write --bitmap \
+ --preferred-pack="pack-$p2.pack" &&
+ test_path_is_file $midx &&
+ test_path_is_file $midx-$(midx_checksum $objdir).bitmap &&
+
++ # When the above circumstances are met, an existing bug
++ # in the MIDX machinery will cause the reverse index to
++ # be read incorrectly, resulting in failed clones (among
++ # other things).
+ test_must_fail git clone --no-local . clone2
+ )
+'
2: 053045db14 = 2: d6648ed88f t/lib-bitmap.sh: avoid silencing stderr
3: 2df8f1e884 = 3: ae2077acb7 midx.c: extract `struct midx_fanout`
4: 92b82c83ea = 4: 2351a9fc27 midx.c: extract `midx_fanout_add_midx_fanout()`
5: db1c6ea8e5 = 5: 845e1484b4 midx.c: extract `midx_fanout_add_pack_fanout()`
6: 4ddddc959b ! 6: d301c4d87f midx.c: include preferred pack correctly with existing MIDX
@@ Commit message
from a single source. (We could still mark these preferred bits, but
doing so is redundant and unnecessary).
- This resolves the bug described in the first patch of this series.
+ This resolves the bug demonstrated by t5326.174 ("preferred pack change
+ with existing MIDX bitmap").
Signed-off-by: Taylor Blau <me@ttaylorr.com>
@@ midx.c: static struct pack_midx_entry *get_sorted_entries(struct multi_pack_inde
## t/t5326-multi-pack-bitmaps.sh ##
@@ t/t5326-multi-pack-bitmaps.sh: test_expect_success 'preferred pack change with existing MIDX bitmap' '
+ git pack-objects --all --unpacked $objdir/pack/pack0 &&
+
+ # Generate a new MIDX which changes the preferred pack
+- # to a pack contained in the existing MIDX, such that
+- # not all objects from p2 that appear in the MIDX had
+- # their copy selected from p2.
++ # to a pack contained in the existing MIDX.
+ git multi-pack-index write --bitmap \
+ --preferred-pack="pack-$p2.pack" &&
test_path_is_file $midx &&
test_path_is_file $midx-$(midx_checksum $objdir).bitmap &&
+- # When the above circumstances are met, an existing bug
+- # in the MIDX machinery will cause the reverse index to
+- # be read incorrectly, resulting in failed clones (among
+- # other things).
- test_must_fail git clone --no-local . clone2
++ # When the above circumstances are met, the preferred
++ # pack should change appropriately and clones should
++ # (still) succeed.
+ git clone --no-local . clone2
)
'
-: ---------- > 7: 887ab9485f midx.c: avoid adding preferred objects twice
--
2.37.0.1.g1379af2e9d
next prev parent reply other threads:[~2022-08-22 19:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 21:30 [PATCH 0/6] midx: permit changing the preferred pack when reusing the MIDX Taylor Blau
2022-08-19 21:30 ` [PATCH 1/6] t5326: demonstrate potential bitmap corruption Taylor Blau
2022-08-22 16:09 ` Derrick Stolee
2022-08-22 17:57 ` Taylor Blau
2022-08-22 19:31 ` Junio C Hamano
2022-08-22 19:41 ` Taylor Blau
2022-08-19 21:30 ` [PATCH 2/6] t/lib-bitmap.sh: avoid silencing stderr Taylor Blau
2022-08-20 16:44 ` Abhradeep Chakraborty
2022-08-22 17:58 ` Taylor Blau
2022-08-19 21:30 ` [PATCH 3/6] midx.c: extract `struct midx_fanout` Taylor Blau
2022-08-19 21:30 ` [PATCH 4/6] midx.c: extract `midx_fanout_add_midx_fanout()` Taylor Blau
2022-08-19 21:30 ` [PATCH 5/6] midx.c: extract `midx_fanout_add_pack_fanout()` Taylor Blau
2022-08-19 21:30 ` [PATCH 6/6] midx.c: include preferred pack correctly with existing MIDX Taylor Blau
2022-08-20 18:40 ` Abhradeep Chakraborty
2022-08-22 18:08 ` Taylor Blau
2022-08-22 17:03 ` Derrick Stolee
2022-08-22 18:14 ` Taylor Blau
2022-08-22 17:04 ` [PATCH 0/6] midx: permit changing the preferred pack when reusing the MIDX Derrick Stolee
2022-08-22 19:44 ` Taylor Blau
2022-08-22 19:50 ` Taylor Blau [this message]
2022-08-22 19:50 ` [PATCH v2 1/7] t5326: demonstrate potential bitmap corruption Taylor Blau
2022-08-22 19:50 ` [PATCH v2 2/7] t/lib-bitmap.sh: avoid silencing stderr Taylor Blau
2022-08-22 19:50 ` [PATCH v2 3/7] midx.c: extract `struct midx_fanout` Taylor Blau
2022-08-22 19:50 ` [PATCH v2 4/7] midx.c: extract `midx_fanout_add_midx_fanout()` Taylor Blau
2022-08-22 19:50 ` [PATCH v2 5/7] midx.c: extract `midx_fanout_add_pack_fanout()` Taylor Blau
2022-08-22 19:50 ` [PATCH v2 6/7] midx.c: include preferred pack correctly with existing MIDX Taylor Blau
2022-08-22 19:50 ` [PATCH v2 7/7] midx.c: avoid adding preferred objects twice Taylor Blau
2022-08-23 16:22 ` Derrick Stolee
2022-08-23 16:23 ` [PATCH v2 0/7] midx: permit changing the preferred pack when reusing the MIDX Derrick Stolee
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=cover.1661197803.git.me@ttaylorr.com \
--to=me@ttaylorr.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chakrabortyabhradeep79@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=kaartic.sivaraam@gmail.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).