On Wed, Oct 29, 2014 at 11:50:12AM -0700, Junio C Hamano wrote:
> Jeff King <[email protected]> writes:
>
> > I'm a little iffy on this just because it is fixing one particular bug,
> > and I am sure there are probably a bunch of other ways to have a bogus
> > index. Fundamentally, I think we pretty much trust that the index was
> > not maliciously generated (unlike packfiles, for instance, which can
> > come from elsewhere). Still, this is one step closer to safe, and the
> > bug was seen in the wild, so maybe it is worth doing.
>
> Is it cheap to sanity-check the input when we map in the cache-tree
> upon read_cache()? Then we can just invalidate the cache-tree,
> either in its entirety (easy) or just the bogus subpart (maybe not
> worth doing).
I think it is not super-expensive, but it is not as easy as:
if (!it->entry_count)
return -1;
> > We could alternatively (or in addition) reject 0-entry cache trees when
> > reading them from disk. The trick, though, is that it is not just
> > records with 0 entries, but ones where the sum of the entries and
> > subtree entries is 0. Given that it is not something we expect to
> > happen, it is easier to catch it here. And we know there can be no
> > regressions for missed corner cases, because the case we are catching
> > here would _always_ have gone into an infinite loop before this patch.
>
> OK. I wonder if we can instead die here but propagate the error
> back up the callchain and have the ultimate caller rebuild the cache
> tree without paying attention to the existing data that we now know
> is bogus.
Yeah, that would make sense to me, but I was not familiar with the
cache-tree code to do it easily (and given that this is not something
that should ever happen, I didn't want to spend time digging in).
I can provide you with a real-world test case if you want to explore it
further.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
