threads / patch / 48187

patchconfig: move flockfile() closer to unlocked functions

Subject: [PATCH] config: move flockfile() closer to unlocked functions

## tl;dr

2 messages between Mar 30, 2018 and Mar 30, 2018. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Jeff King· Mar 30, 2018, 19:26 UTC · lore
On Fri, Mar 30, 2018 at 09:04:13PM +0200, Johannes Schindelin wrote:
> > Probably the flockfile should go into do_config_from_file(), where we
> > specify to use the unlocked variants.
> 
> Ah, that makes sense now! I am glad I could also help ;-)
:)
Show 5 quoted lines
> > Yeah, I'll wait to see how your refactor turns out.
> 
> I don't think I'll touch too much in that part of the code. My changes
> should not cause merge conflicts with a patch moving the
> flockfile()/funlockfile() calls to do_config_from_file().
OK, then let's do this while we're thinking about it:
-- >8 --
Subject: config: move flockfile() closer to unlocked functions

Commit 260d408e32 (config: use getc_unlocked when reading from file, 2015-04-16) taught git_config_from_file() to lock the filehandle so that we could safely use the faster unlocked functions to access the handle.

However, it split the logic into two places:
  1. The master lock/unlock happens in git_config_from_file().
  2. The decision to use the unlocked functions happens in
     do_config_from_file().

That means that if anybody calls the latter function, they will accidentally use the unlocked functions without holding the lock. And indeed, git_config_from_stdin() does so.

In practice, this hasn't been a problem since this code isn't generally multi-threaded (and even if some Git program happened to have another thread running, it's unlikely to be reading from stdin). But it's a good practice to make sure we're always holding the lock before using the unlocked functions.

Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
---
I wasn't sure if this was "helped by" or "reported by" or
"stumbled-upon-by". :)
 config.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
Show changes to config.c +5 −3
diff --git a/config.c b/config.c
index b0c20e6cb8..609ef2f58b 100644
--- a/config.c
+++ b/config.c
@@ -1426,6 +1426,7 @@ static int do_config_from_file(config_fn_t fn,
 		void *data)
 {
 	struct config_source top;
+	int ret;
 
 	top.u.file = f;
 	top.origin_type = origin_type;
@@ -1436,7 +1437,10 @@ static int do_config_from_file(config_fn_t fn,
 	top.do_ungetc = config_file_ungetc;
 	top.do_ftell = config_file_ftell;
 
-	return do_config_from(&top, fn, data);
+	flockfile(f);
+	ret = do_config_from(&top, fn, data);
+	funlockfile(f);
+	return ret;
 }
 
 static int git_config_from_stdin(config_fn_t fn, void *data)
@@ -1451,9 +1455,7 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 
 	f = fopen_or_warn(filename, "r");
 	if (f) {
-		flockfile(f);
 		ret = do_config_from_file(fn, CONFIG_ORIGIN_FILE, filename, filename, f, data);
-		funlockfile(f);
 		fclose(f);
 	}
 	return ret;
-- 
2.17.0.rc2.594.gdb94a0ce02
Junio C Hamano· Mar 30, 2018, 19:52 UTC · re: Jeff King · lore

Re: [PATCH] config: move flockfile() closer to unlocked functions

Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> On Fri, Mar 30, 2018 at 09:04:13PM +0200, Johannes Schindelin wrote:
>
>> > Probably the flockfile should go into do_config_from_file(), where we
>> > specify to use the unlocked variants.
>> 
>> Ah, that makes sense now! I am glad I could also help ;-)
>
> :)
>
>> > Yeah, I'll wait to see how your refactor turns out.
>> 
>> I don't think I'll touch too much in that part of the code. My changes
>> should not cause merge conflicts with a patch moving the
>> flockfile()/funlockfile() calls to do_config_from_file().
>
> OK, then let's do this while we're thinking about it:

Yup, what Dscho found was quite amusing ;-) and this obviously makes the code clearer to follow.

Will queue, thanks.

← back to recent threads