Re: MSan failures in pack-bitmap

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 9, 2024, 20:23 UTC
Message-ID: <xmqqh6e1c1bf.fsf@gitster.g>
In-Reply-To: <ZmYJ+d3+j1E08Ms/@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 5 quoted lines

> I don't think the issue here is a corrupt on-disk bitmap or MIDX. The
> regression that Kyle reported was a logic issue reading a
> ordinary/non-corrupt MIDX file, not a result of some on-disk corruption.
> ...
> But I do not think that repository corruption is a likely outcome here,

Yes, exactly. What I was asking was how on-disk corruption that would result from the logic issue of reading a correct MIDX file.

Show 6 quoted lines

> A more likely outcome would be if a Git client who was using MIDX
> bitmaps, but only doing single-pack reuse tried to generate a pack
> to push to some remote (or vice-versa, replacing client and
> server/remote) which ended up being corrupt in some fashion. I
> haven't had enough of a chance to determine if this possible,
> though I suspect it is.

So, ...

Show 5 quoted lines

>> > Unfortunately, the regression happened in 795006fff4, so this is in a
>> > released version of Git. But this is all behind a configuration option,
>> > so affected users can reasonably work around this issue.
>>
>> Can you elaborate a bit about "reasonably work around"?

... there is no reasonable work around here, is there? We do not even know exactly what kind of breakage this will cause (which is expected, as we would be "reading" a garbage value and basing future actions on it)?