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

Re: [PATCH v2 7/8] csum-file: introduce hashfile_checkpoint_init()

From
Taylor Blau <me@ttaylorr.com>
Date
Jan 17, 2025, 21:30 UTC
Message-ID
<Z4rL3TbEeR8EiUOi@nand.local>
In-Reply-To
<Z4GWIZkJOUa278VA@nand.local>
On Fri, Jan 10, 2025 at 04:50:25PM -0500, Taylor Blau wrote:
Show 24 quoted lines
> On Fri, Jan 10, 2025 at 05:37:56AM -0500, Jeff King wrote:
> > So in the new constructor:
> >
> > > +void hashfile_checkpoint_init(struct hashfile *f,
> > > +			      struct hashfile_checkpoint *checkpoint)
> > > +{
> > > +	memset(checkpoint, 0, sizeof(*checkpoint));
> > > +	f->algop->init_fn(&checkpoint->ctx);
> > > +}
> >
> > ...should we actually record "f" itself? And then in the existing
> > functions:
> >
> > >  void hashfile_checkpoint(struct hashfile *f, struct hashfile_checkpoint *checkpoint)
> >
> > ...they'd no longer need to take the extra parameter.
> >
> > It creates a lifetime dependency of the checkpoint struct on the "f" it
> > is checkpointing, but I think that is naturally modeling the domain.
>
> Thanks, I really like these suggestions. I adjusted the series
> accordingly to do this cleanup in two patches (one for
> hashfile_checkpoint(), another for hashfile_truncate()) after the patch
> introducing hashfile_checkpoint_init().
Hmm. I'm not sure that I like this as much as I thought I did.

I agree with you that ultimately the hashfile_checkpoint is (or should be) tied to the lifetime of the hashfile that it is checkpointing underneath. But in practice things are a little funky.

Let's suppose I did something like the following:
--- 8< ---
diff --git a/csum-file.c b/csum-file.c
index ebffc80ef7..47b8317a1f 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -206,6 +206,15 @@ struct hashfile *hashfd_throughput(int fd, const char *name, struct progress *tp
 	return hashfd_internal(fd, name, tp, 8 * 1024);
 }

+void hashfile_checkpoint_init(struct hashfile *f,
+			      struct hashfile_checkpoint *checkpoint)
+{
+	memset(checkpoint, 0, sizeof(*checkpoint));
+
+	checkpoint->f = f;
+	checkpoint->f->algop->init_fn(&checkpoint->ctx);
+}
+
 void hashfile_checkpoint(struct hashfile *f, struct hashfile_checkpoint *checkpoint)
 {
 	hashflush(f);
diff --git a/csum-file.h b/csum-file.h
index 2b45f4673a..8016509c71 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -34,8 +34,10 @@ struct hashfile {
 struct hashfile_checkpoint {
 	off_t offset;
 	git_hash_ctx ctx;
+	struct hashfile *f;
 };

+void hashfile_checkpoint_init(struct hashfile *, struct hashfile_checkpoint *);
 void hashfile_checkpoint(struct hashfile *, struct hashfile_checkpoint *);
 int hashfile_truncate(struct hashfile *, struct hashfile_checkpoint *);
--- >8 ---

, where I'm eliding the trivial changes necessary to make this work at
the two callers. Let's look a little closer at the bulk-checkin caller.
If I do this on top:

--- 8< ---
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 433070a3bd..892176d23d 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -261,7 +261,7 @@ static int deflate_blob_to_pack(struct bulk_checkin_packfile *state,
 	git_hash_ctx ctx;
 	unsigned char obuf[16384];
 	unsigned header_len;
-	struct hashfile_checkpoint checkpoint = {0};
+	struct hashfile_checkpoint checkpoint;
 	struct pack_idx_entry *idx = NULL;

 	seekback = lseek(fd, 0, SEEK_CUR);
@@ -272,12 +272,15 @@ static int deflate_blob_to_pack(struct bulk_checkin_packfile *state,
 					  OBJ_BLOB, size);
 	the_hash_algo->init_fn(&ctx);
 	the_hash_algo->update_fn(&ctx, obuf, header_len);
-	the_hash_algo->unsafe_init_fn(&checkpoint.ctx);

 	/* Note: idx is non-NULL when we are writing */
-	if ((flags & HASH_WRITE_OBJECT) != 0)
+	if ((flags & HASH_WRITE_OBJECT) != 0) {
 		CALLOC_ARRAY(idx, 1);

+		prepare_to_stream(state, flags);
+		hashfile_checkpoint_init(state->f, &checkpoint);
+	}
+
 	already_hashed_to = 0;

 	while (1) {
--- >8 ---

then test 14 in t1050-large.sh fails because of a segfault in 'git add'.
If we compile with SANITIZE=address, we can see that there's a
use-after-free in hashflush(), which is called by hashfile_checkpoint().

That is a result of the max pack-size code. So we could try something
like:

--- 8< ---
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 7b8a6eb2df..9dc114d132 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -261,7 +261,7 @@ static int deflate_blob_to_pack(struct bulk_checkin_packfile *state,
 	git_hash_ctx ctx;
 	unsigned char obuf[16384];
 	unsigned header_len;
-	struct hashfile_checkpoint checkpoint;
+	struct hashfile_checkpoint checkpoint = { 0 };
 	struct pack_idx_entry *idx = NULL;

 	seekback = lseek(fd, 0, SEEK_CUR);
@@ -274,17 +274,14 @@ static int deflate_blob_to_pack(struct bulk_checkin_packfile *state,
 	the_hash_algo->update_fn(&ctx, obuf, header_len);

 	/* Note: idx is non-NULL when we are writing */
-	if ((flags & HASH_WRITE_OBJECT) != 0) {
+	if ((flags & HASH_WRITE_OBJECT) != 0)
 		CALLOC_ARRAY(idx, 1);
-
-		prepare_to_stream(state, flags);
-		hashfile_checkpoint_init(state->f, &checkpoint);
-	}
-
 	already_hashed_to = 0;

 	while (1) {
 		prepare_to_stream(state, flags);
+		if (checkpoint.f != state->f)
+			hashfile_checkpoint_init(state->f, &checkpoint);
 		if (idx) {
 			hashfile_checkpoint(&checkpoint);
 			idx->offset = state->offset;
--- >8 ---

which would do the trick, but it feels awfully hacky to have the "if
(checkpoint.f != state->f)" check in there, since that feels too
intimately tied to the implementation of the hashfile_checkpoint API for
my comfort.

It would be nice if we could make the checkpoint only declared within
the loop body itself, but we can't because we need to call
hashfile_truncate() outside of the loop.

Anyway, that's all to say that I think that while this is probably
doable in theory, in practice it's kind of a mess, at least currently.
I would rather see if there are other ways to clean up the
deflate_blob_to_pack() function first in a way that made this change
less awkward.

I think the most reasonable course here would be to pursue a minimal
change like the one presented here and then think about further clean up
as a separate step.

Thanks,
Taylor
Previous: Taylor BlauNext: Jeff King
Message 30 of 60 in “hash: introduce unsafe_hash_algo(), drop unsafe_ variants”
  1. 0/6 hash: introduce unsafe_hash_algo(), drop unsafe_ variantsTaylor Blau, Nov 20, 2024
  2. 1/6 csum-file: store the hash algorithm as a struct fieldTaylor Blau, Nov 20, 2024
  3. Jeff KingNov 21, 2024
  4. 2/6 csum-file.c: extract algop from hashfile_checksum_valid()Taylor Blau, Nov 20, 2024
  5. 3/6 hash.h: introduce `unsafe_hash_algo()`Taylor Blau, Nov 20, 2024
  6. Jeff KingNov 21, 2024
  7. brian m. carlsonNov 22, 2024
  8. Jeff KingNov 22, 2024
  9. brian m. carlsonNov 22, 2024
  10. Taylor BlauJan 10, 2025
  11. Jeff KingJan 11, 2025
  12. 4/6 csum-file.c: use unsafe_hash_algo()Taylor Blau, Nov 20, 2024
  13. 5/6 t/helper/test-hash.c: use unsafe_hash_algo()Taylor Blau, Nov 20, 2024
  14. 6/6 hash.h: drop unsafe_ function variantsTaylor Blau, Nov 20, 2024
  15. Jeff KingNov 21, 2024
  16. 0/8 hash: introduce unsafe_hash_algo(), drop unsafe_ variantsTaylor Blau, Jan 8, 2025
  17. 1/8 t/helper/test-tool: implement sha1-unsafe helperTaylor Blau, Jan 8, 2025
  18. 2/8 csum-file: store the hash algorithm as a struct fieldTaylor Blau, Jan 8, 2025
  19. Patrick SteinhardtJan 16, 2025
  20. Taylor BlauJan 17, 2025
  21. 3/8 csum-file.c: extract algop from hashfile_checksum_valid()Taylor Blau, Jan 8, 2025
  22. 4/8 hash.h: introduce `unsafe_hash_algo()`Taylor Blau, Jan 8, 2025
  23. Patrick SteinhardtJan 16, 2025
  24. Taylor BlauJan 17, 2025
  25. 5/8 csum-file.c: use unsafe_hash_algo()Taylor Blau, Jan 8, 2025
  26. 6/8 t/helper/test-hash.c: use unsafe_hash_algo()Taylor Blau, Jan 8, 2025
  27. 7/8 csum-file: introduce hashfile_checkpoint_init()Taylor Blau, Jan 8, 2025
  28. Jeff KingJan 10, 2025
  29. Taylor BlauJan 10, 2025
  30. Taylor BlauJan 17, 2025
  31. Jeff KingJan 18, 2025
  32. 8/8 hash.h: drop unsafe_ function variantsTaylor Blau, Jan 8, 2025
  33. Jeff KingJan 10, 2025
  34. Taylor BlauJan 10, 2025
  35. Jeff KingJan 11, 2025
  36. Junio C HamanoJan 11, 2025
  37. Taylor BlauJan 11, 2025
  38. 0/8 hash: introduce unsafe_hash_algo(), drop unsafe_ variantsTaylor Blau, Jan 17, 2025
  39. 1/8 t/helper/test-tool: implement sha1-unsafe helperTaylor Blau, Jan 17, 2025
  40. 2/8 csum-file: store the hash algorithm as a struct fieldTaylor Blau, Jan 17, 2025
  41. 3/8 csum-file.c: extract algop from hashfile_checksum_valid()Taylor Blau, Jan 17, 2025
  42. 4/8 hash.h: introduce `unsafe_hash_algo()`Taylor Blau, Jan 17, 2025
  43. 5/8 csum-file.c: use unsafe_hash_algo()Taylor Blau, Jan 17, 2025
  44. 6/8 t/helper/test-hash.c: use unsafe_hash_algo()Taylor Blau, Jan 17, 2025
  45. 7/8 csum-file: introduce hashfile_checkpoint_init()Taylor Blau, Jan 17, 2025
  46. 8/8 hash.h: drop unsafe_ function variantsTaylor Blau, Jan 17, 2025
  47. Jeff KingJan 18, 2025
  48. Jeff KingJan 18, 2025
  49. Junio C HamanoJan 22, 2025
  50. 0/8 hash: introduce unsafe_hash_algo(), drop unsafe_ variantsTaylor Blau, Jan 23, 2025
  51. 1/8 t/helper/test-tool: implement sha1-unsafe helperTaylor Blau, Jan 23, 2025
  52. 2/8 csum-file: store the hash algorithm as a struct fieldTaylor Blau, Jan 23, 2025
  53. 3/8 csum-file.c: extract algop from hashfile_checksum_valid()Taylor Blau, Jan 23, 2025
  54. 4/8 hash.h: introduce `unsafe_hash_algo()`Taylor Blau, Jan 23, 2025
  55. 5/8 csum-file.c: use unsafe_hash_algo()Taylor Blau, Jan 23, 2025
  56. 6/8 t/helper/test-hash.c: use unsafe_hash_algo()Taylor Blau, Jan 23, 2025
  57. 7/8 csum-file: introduce hashfile_checkpoint_init()Taylor Blau, Jan 23, 2025
  58. 8/8 hash.h: drop unsafe_ function variantsTaylor Blau, Jan 23, 2025
  59. Junio C HamanoJan 23, 2025
  60. Jeff KingJan 23, 2025

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.