Thread (8 messages) flat view 8 messages, 3 authors, 2021-01-06
STALE2054d

[PATCH 3/5] midx: don't peek into `struct lock_file`

From: Martin Ågren <hidden>
Date: 2021-01-05 19:26:18
Subsystem: the rest · Maintainer: Linus Torvalds

Similar to the previous commits, avoid peeking into the `struct
lock_file`. Use the lock file API instead.

The two functions we're calling here double-check that the tempfile is
indeed "active", which is arguably overkill considering how we took the
lock on the line immediately above. More importantly, this future-proofs
us against, e.g., other code appearing between these two lines or the
lock file and/or tempfile internals changing.

Signed-off-by: Martin Ågren <redacted>
---
 midx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/midx.c b/midx.c
index 79c282b070..9d41b9c271 100644
--- a/midx.c
+++ b/midx.c
@@ -918,7 +918,7 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index *
 					(pack_name_concat_len % MIDX_CHUNK_ALIGNMENT);
 
 	hold_lock_file_for_update(&lk, midx_name, LOCK_DIE_ON_ERROR);
-	f = hashfd(lk.tempfile->fd, lk.tempfile->filename.buf);
+	f = hashfd(get_lock_file_fd(&lk), get_lock_file_path(&lk));
 	FREE_AND_NULL(midx_name);
 
 	if (packs.m)
-- 
2.30.0
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help