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

Re: [PATCH 1/3] connect: treat generic proxy processes like ssh processes

From
Johannes Sixt <j6t@kdbg.org>
Date
May 16, 2011, 19:57 UTC
Message-ID
<4DD181C6.4020104@kdbg.org>
In-Reply-To
<20110516064607.GA19078@sigill.intra.peff.net>
Am 16.05.2011 08:46, schrieb Jeff King:
Show 20 quoted lines
> The git_connect function returns two ends of a pipe for
> talking with a remote, plus a struct child_process
> representing the other end of the pipe. If we have a direct
> socket connection, then this points to a special "no_fork"
> child process.
> 
> The code path for doing git-over-pipes or git-over-ssh sets
> up this child process to point to the child git command or
> the ssh process. When we call finish_connect eventually, we
> check wait() on the command and report its return value.
> 
> The code path for git://, on the other hand, always sets it
> to no_fork. In the case of a direct TCP connection, this
> makes sense; we have no child process. But in the case of a
> proxy command (configured by core.gitproxy), we do have a
> child process, but we throw away its pid, and therefore
> ignore its return code.
> 
> Instead, let's keep that information in the proxy case, and
> respect its return code, which can help catch some errors

This patch looks strikingly familiar. I had written an almost identical change more than 3 years ago and forgot about it, though the justification I noted in the commit was more to properly shutdown the proxy process rather than to abandon it and let it be collected by init(8). Your justification is much better.

There's one problem with your implementation, though:
Show 25 quoted lines
> -static void git_proxy_connect(int fd[2], char *host)
> +static struct child_process *git_proxy_connect(int fd[2], char *host)
>  {
>  	const char *port = STR(DEFAULT_GIT_PORT);
>  	char *colon, *end;
>  	const char *argv[4];
> -	struct child_process proxy;
> +	struct child_process *proxy;
>  
>  	if (host[0] == '[') {
>  		end = strchr(host + 1, ']');
> @@ -431,14 +431,15 @@ static void git_proxy_connect(int fd[2], char *host)
>  	argv[1] = host;
>  	argv[2] = port;
>  	argv[3] = NULL;
> -	memset(&proxy, 0, sizeof(proxy));
> -	proxy.argv = argv;
> -	proxy.in = -1;
> -	proxy.out = -1;
> -	if (start_command(&proxy))
> +	proxy = xcalloc(1, sizeof(*proxy));
> +	proxy->argv = argv;
> +	proxy->in = -1;
> +	proxy->out = -1;
> +	if (start_command(proxy))

At this point, proxy->argv would point to automatic storage; but we need argv[0] in finish_command() for error reporting. In my implementation, I xmalloced the pointer array and leaked it. (And that's probably the reason that I never submitted the patch.) I wouldn't dare to make argv just static because this limits us to have just one open connection at a time established via git_proxy_connect(). Dunno...

Below is the interdiff that turns your patch into mine, mostly for exposition: The two hunks in git_connect() are just cosmetic differences. But the first hunk should be squashed into your patch to fix a potential crash in an error situation (e.g., when the proxy dies from a signal) at the cost of a small memory leak.

diff --git a/connect.c b/connect.c
index a28e084..8668913 100644
--- a/connect.c
+++ b/connect.c
@@ -399,9 +399,10 @@ static struct child_process *git_proxy_connect(int fd[2], char *host)
 {
 	const char *port = STR(DEFAULT_GIT_PORT);
-	const char *argv[4];
+	const char **argv;
 	struct child_process *proxy;
 
 	get_host_and_port(&host, &port);
 
+	argv = xmalloc(4*sizeof(*argv));
 	argv[0] = git_proxy_command;
 	argv[1] = host;
@@ -457,5 +458,5 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 	char *end;
 	int c;
-	struct child_process *conn;
+	struct child_process *conn = &no_fork;
 	enum protocol protocol = PROTO_LOCAL;
 	int free_path = 0;
@@ -543,8 +544,6 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		if (git_use_proxy(host))
 			conn = git_proxy_connect(fd, host);
-		else {
+		else
 			git_tcp_connect(fd, host, flags);
-			conn = &no_fork;
-		}
 		/*
 		 * Separate original protocol components prog and path
Previous: Jeff KingNext: Junio C Hamano
Message 16 of 53 in “receive-pack: Add receive.denyObjectLimit to refuse push with too many objects”
  1. 2/2 receive-pack: Add receive.denyObjectLimit to refuse push with too many objectsJohan Herland, May 13, 2011
  2. Junio C HamanoMay 13, 2011
  3. Johan HerlandMay 14, 2011
  4. 2/2 receive-pack: Add receive.objectCountLimit to refuse push with too many objectsJohan Herland, May 14, 2011
  5. Shawn PearceMay 14, 2011
  6. Johan HerlandMay 14, 2011
  7. Shawn PearceMay 14, 2011
  8. Johan HerlandMay 15, 2011
  9. 0/9 Push limitsJohan Herland, May 15, 2011
  10. 1/9 Update technical docs to reflect side-band-64k capability in receive-packJohan Herland, May 15, 2011
  11. 2/9 send-pack: Attempt to retrieve remote status even if pack-objects failsJohan Herland, May 15, 2011
  12. Jeff KingMay 16, 2011
  13. Jeff KingMay 16, 2011
  14. Jeff KingMay 16, 2011
  15. 1/3 connect: treat generic proxy processes like ssh processesJeff King, May 16, 2011
  16. Johannes SixtMay 16, 2011
  17. Junio C HamanoMay 16, 2011
  18. Jeff KingMay 17, 2011
  19. Johannes SixtMay 17, 2011
  20. Jeff KingMay 18, 2011
  21. 2/3 connect: let callers know if connection is a socketJeff King, May 16, 2011
  22. 3/3 send-pack: avoid deadlock on git:// push with failed pack-objectsJeff King, May 16, 2011
  23. Johannes SixtMay 16, 2011
  24. Jeff KingMay 17, 2011
  25. Windows: add a wrapper for the shutdown() system callJohannes Sixt, May 18, 2011
  26. 3/9 pack-objects: Allow --max-pack-size to be used together with --stdoutJohan Herland, May 15, 2011
  27. Shawn PearceMay 15, 2011
  28. Johan HerlandMay 16, 2011
  29. Junio C HamanoMay 16, 2011
  30. Johan HerlandMay 16, 2011
  31. 4/9 pack-objects: Teach new option --max-object-count, similar to --max-pack-sizeJohan Herland, May 15, 2011
  32. Shawn PearceMay 15, 2011
  33. Johan HerlandMay 15, 2011
  34. Shawn PearceMay 15, 2011
  35. Junio C HamanoMay 16, 2011
  36. Johan HerlandMay 16, 2011
  37. 5/9 pack-objects: Teach new option --max-commit-count, limiting #commits in packJohan Herland, May 15, 2011
  38. 6/9 receive-pack: Prepare for addition of the new 'limit-*' family of capabilitiesJohan Herland, May 15, 2011
  39. Junio C HamanoMay 16, 2011
  40. Johan HerlandMay 16, 2011
  41. Sverre RabbelierMay 16, 2011
  42. Junio C HamanoMay 16, 2011
  43. Sverre RabbelierMay 16, 2011
  44. Junio C HamanoMay 16, 2011
  45. Sverre RabbelierMay 16, 2011
  46. 7/9 send-pack/receive-pack: Allow server to refuse pushes with too many objectsJohan Herland, May 15, 2011
  47. 8/9 send-pack/receive-pack: Allow server to refuse pushing too large packsJohan Herland, May 15, 2011
  48. 9/9 send-pack/receive-pack: Allow server to refuse pushes with too many commitsJohan Herland, May 15, 2011
  49. Ævar Arnfjörð BjarmasonMay 15, 2011
  50. Junio C HamanoMay 14, 2011
  51. Shawn PearceMay 14, 2011
  52. Johannes SixtMay 13, 2011
  53. Johan HerlandMay 14, 2011

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.