Re: [PATCH 1/2] commit-graph.c: remove temporary graph layers on exit

From: Jeff King <peff@peff.net>
Date: Jun 8, 2024, 09:53 UTC
Message-ID: <20240608095322.GB2659849@coredump.intra.peff.net>
In-Reply-To: <25324fea5b7c7f748d7f4e1e40299c0af04006e8.1717712358.git.me@ttaylorr.com>

On Thu, Jun 06, 2024 at 06:19:25PM -0400, Taylor Blau wrote:

Show 19 quoted lines

> @@ -2035,24 +2035,23 @@ static int write_commit_graph_file(struct write_commit_graph_context *ctx)
>  					       LOCK_DIE_ON_ERROR, 0444);
>  		free(lock_name);
>  
> -		fd = git_mkstemp_mode(ctx->graph_name, 0444);
> -		if (fd < 0) {
> +		graph_layer = mks_tempfile_m(ctx->graph_name, 0444);
> +		if (!graph_layer) {
>  			error(_("unable to create temporary graph layer"));
>  			return -1;
>  		}
>  
> -		if (adjust_shared_perm(ctx->graph_name)) {
> +		if (adjust_shared_perm(get_tempfile_path(graph_layer))) {
>  			error(_("unable to adjust shared permissions for '%s'"),
> -			      ctx->graph_name);
> +			      get_tempfile_path(graph_layer));
>  			return -1;
>  		}

Most errors will cause us to die(), but this "return" and the one that Junio noted later (when renaming the base graph file fails) mean we'll return with the tempfile still active. We'll clean it up when the program exits, but if there were a long-running program that called write_commit_graph_file(), that tempfile might hang around longer than necessary.

But that is the same strategy that the existing code uses for the lock we use for the chain filename! And it is much worse there, because now it is not just a tempfile hanging around, but we're blocking anybody else from taking the lock.

So I think it would be OK to punt on this for now. Your patch is not making the situation worse, and it's all a problem for a hypothetical libification of this function.

Show 22 quoted lines

> +test_expect_success 'temporary graph layer is discarded upon failure' '
> +	git init layer-discard &&
> +	(
> +		cd layer-discard &&
> +
> +		test_commit A &&
> +		test_commit B &&
> +
> +		# Intentionally remove commit "A" from the object store
> +		# so that the commit-graph machinery fails to parse the
> +		# parents of "B".
> +		#
> +		# This takes place after the commit-graph machinery has
> +		# initialized a new temporary file to store the contents
> +		# of the new graph layer, so will allow us to ensure
> +		# that the temporary file is discarded upon failure.
> +		rm $objdir/$(test_oid_to_path $(git rev-parse HEAD^)) &&
> +
> +		test_must_fail git commit-graph write --reachable --split &&
> +		test_dir_is_empty $graphdir
> +	)
> +'

I'm glad you were able to come up with a case that fails cleanly and non-racily. The exit code of rev-parse will be lost. I doubt that it matters in practice, but I wouldn't be surprised if our shell linting eventually learns to complain about this spot.

Looks like there are a few similar ones in the test suite already, from t5329. I'd be content to leave it for now and deal with it later if somebody really wants to go on a crusade against lost exit codes.

-Peff