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

Re: [PATCH 1/3] improve reliability of fixup_pack_header_footer()

From
Shawn O. Pearce <spearce@spearce.org>
Date
Aug 29, 2008, 04:44 UTC
Message-ID
<20080829044459.GA28492@spearce.org>
In-Reply-To
<1219975624-7653-1-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> wrote:
> Currently, this function has the potential to read corrupted pack data
> from disk and give it a valid SHA1 checksum.  Let's add the ability to
> validate SHA1 checksum of existing data along the way, including before
> and after any arbitrary point in the pack.
I found your implementation in fixup_pack_header to be very
contorted.  Did you read the JGit patch I posted?  I think its
implementation is more elegant and easier to follow.  Oh, and its
BSD licensed... so easy for a GPLv2 project to borrow.  ;-)
 
>  void fixup_pack_header_footer(int pack_fd,
...
> +	if (partial_pack_sha1 && !partial_pack_offset) {
> +		partial_pack_offset = lseek(pack_fd, 0, SEEK_CUR);
> +		if (partial_pack_offset == (off_t)-1)
Eh?

I find this to be nonsense. If the caller gave us a SHA-1 but wants us to do fixup then they have increased the size of the pack. Which means they must pass us the original length. Computing it here is relying on the caller leaving the file pointer positioned at the old end. Who the heck does that after fixing a thin pack?

Show 7 quoted lines
>  	buf = xmalloc(buf_sz);
>  	for (;;) {
> -		ssize_t n = xread(pack_fd, buf, buf_sz);
> +		ssize_t m, n;
> +		m = (partial_pack_sha1 && partial_pack_offset < buf_sz) ?
> +			partial_pack_offset : buf_sz;
> +		n = xread(pack_fd, buf, m);

Why not read the full buf_sz per round and then use only part of the buffer in SHA1_Update(&old_sha1_ctx)? It took me a while to figure out what the heck you were trying to measure here. It also would be a few less CPU instructions if you always just read buf_sz and leave the min test to after the "if (!partial_pack_sha1)" below.

Show 19 quoted lines
> +		if (!partial_pack_sha1)
> +			continue;
> +
> +		SHA1_Update(&old_sha1_ctx, buf, n);
> +		partial_pack_offset -= n;
> +		if (partial_pack_offset == 0) {
> +			unsigned char sha1[20];
> +			SHA1_Final(sha1, &old_sha1_ctx);
> +			if (hashcmp(sha1, partial_pack_sha1) != 0)
> +				die("Unexpected checksum for %s "
> +				    "(disk corruption?)", pack_name);
> +			/*
> +			 * Now let's compute the SHA1 of the remainder of the
> +			 * pack, which also means making partial_pack_offset
> +			 * big enough not to matter anymore.
> +			 */
> +			SHA1_Init(&old_sha1_ctx);
> +			partial_pack_offset = ~partial_pack_offset;
> +			partial_pack_offset -= MSB(partial_pack_offset, 1);
That's freaking brilliant.  And something I missed in JGit.

The way its implemented is downright difficult to follow though. I'll admit it took me a good 10 minutes to understand what you were doing here, and why.

-- 
Shawn.
Previous: Nicolas PitreNext: Nicolas Pitre
Message 5 of 16 in “don't let disk corruptions escape pack SHA1 checksum”
  1. 0/3 don't let disk corruptions escape pack SHA1 checksumNicolas Pitre, Aug 29, 2008
  2. 1/3 improve reliability of fixup_pack_header_footer()Nicolas Pitre, Aug 29, 2008
  3. 2/3 pack-objects: use fixup_pack_header_footer()'s validation modeNicolas Pitre, Aug 29, 2008
  4. 3/3 index-pack: use fixup_pack_header_footer()'s validation modeNicolas Pitre, Aug 29, 2008
  5. Shawn O. PearceAug 29, 2008
  6. Nicolas PitreAug 29, 2008
  7. Shawn O. PearceAug 29, 2008
  8. 0/5 pack header rewriting improvementsNicolas Pitre, Aug 29, 2008
  9. 1/5 pack-objects: improve returned information from write_one()Nicolas Pitre, Aug 29, 2008
  10. 2/5 improve reliability of fixup_pack_header_footer()Nicolas Pitre, Aug 29, 2008
  11. 3/5 pack-objects: use fixup_pack_header_footer()'s validation modeNicolas Pitre, Aug 29, 2008
  12. 4/5 index-pack: use fixup_pack_header_footer()'s validation modeNicolas Pitre, Aug 29, 2008
  13. 5/5 fixup_pack_header_footer(): use nicely aligned buffer sizesNicolas Pitre, Aug 29, 2008
  14. Junio C HamanoAug 31, 2008
  15. Nicolas PitreAug 29, 2008
  16. Shawn O. PearceAug 29, 2008

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.