Re: [PATCH] Fix random fast-import errors when compiled with NO_MMAP

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 19, 2008, 03:55 UTC
Message-ID: <alpine.LFD.1.00.0801181953130.2957@woody.linux-foundation.org>
In-Reply-To: <7vwsq6a44w.fsf@gitster.siamese.dyndns.org>

On Fri, 18 Jan 2008, Junio C Hamano wrote:

Show 17 quoted lines

> 
> gfi uses data in a "pack" in two quite different ways.
> 
> A new object is written to an unfinalized pack.  Such a pack
> already has "struct packed_git" allocated for it and a pointer
> to it is held in pack_data.  As far as the core part of git
> (that is, sha1_file.c) is concerned, however, this pack does not
> even exist.  It is still not part of packed_git list in
> sha1_file.c, and read_sha1_file() will not see objects in it, as
> no idx into the packfile exists yet.  gfi has a table of objects
> in this pack and uses gfi_unpack_entry() function to retrieve
> data from it.
> 
> A packfile is finalized in end_packfile().  The pack header and
> footer is recomputed, an idx file is written, and the pack is
> finally registered.  Before that time p->index_data is not even
> used for that pack (it is initialized with NULL).

Oh, ok. I did try to grep for index_data, and didn't find anything that looked bad, but the incestuous things that fast-import.c does just made me worry - but I was too lazy to really follow it all. It's one of those files I don't think I've ever had anything what-so-ever to do with.

> So I do not think "index_data usage" can be incorrect, as there
> won't be any index_data usage with unfinalized pack, and the
> core part of git would not even have any mmap(2) (nor open fd)
> into its idx file before it is finalized.

In that case, I think Shawn fixed it all, and we're all good, and it's not just hidden well enough that it "just happens" to work.

				Linus