From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] bundle: avoid closing file descriptor twice
Date: Sat, 25 Jan 2025 18:49:56 -0800 [thread overview]
Message-ID: <xmqqa5bewap7.fsf@gitster.g> (raw)
In-Reply-To: <pull.1857.git.1737849456338.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Sat, 25 Jan 2025 23:57:36 +0000")
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> This seems not to have caused too many problems in almost two decades,
> but I encountered a situation today where it _does_ cause problems: In
> i686 variants of Git for Windows, it seems that file descriptors are
> reused quickly after they have been closed.
Nice finding. It pays not to be in too uniform a monoculture.
> This is a really old bug. Deviating from Git's practice, I did not apply
> this on top of the bugged commit. In fact, I did not even apply this on
> top of an older maint-* branch because it would cause conflicts even
> cherry-picking it on top of maint-2.47.
Just for fun, attached is my backport to maint-2.44 track. It
merges, with conflict which is rather trivial to resolve, back to
v2.48.1, on which your original patch is based, and gives the
merge result identical to the result of direct application of your
patch to v2.48.1.
I am not sure what to feel about the FD leak mentioned in the log
message, though.
Thanks, will queue.
--- >8 ---
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 25 Jan 2025 23:57:36 +0000
Subject: [PATCH] bundle: avoid closing file descriptor twice
Already when introduced in c7a8a16239 (Add bundle transport,
2007-09-10), the `bundle` transport had a bug where it would open a file
descriptor to the bundle file and then close it _twice_: First, ...
... At least this here patch is relatively easy to reason about, and
addresses a hard failure (`fatal: mmap: could not determine filesize`)
at the expense of leaking a file descriptor under very rare
circumstances in which `git fetch` would error out anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
bundle.c | 4 +++-
bundle.h | 2 ++
transport.c | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
Obviously this is hard to test ;-)
diff --git a/bundle.c b/bundle.c
index a9744da255..7b3f2da40f 100644
--- a/bundle.c
+++ b/bundle.c
@@ -616,8 +616,10 @@ int unbundle(struct repository *r, struct bundle_header *header,
{
struct child_process ip = CHILD_PROCESS_INIT;
- if (verify_bundle(r, header, flags))
+ if (verify_bundle(r, header, flags)) {
+ close(bundle_fd);
return -1;
+ }
strvec_pushl(&ip.args, "index-pack", "--fix-thin", "--stdin", NULL);
diff --git a/bundle.h b/bundle.h
index 021adbdcbb..8b187be7cf 100644
--- a/bundle.h
+++ b/bundle.h
@@ -50,6 +50,8 @@ int verify_bundle(struct repository *r, struct bundle_header *header,
*
* Before unbundling, this method will call verify_bundle() with the
* given 'flags'.
+ *
+ * Note that the `bundle_fd` will be closed as part of the operation.
*/
int unbundle(struct repository *r, struct bundle_header *header,
int bundle_fd, struct strvec *extra_index_pack_args,
diff --git a/transport.c b/transport.c
index df518ead70..25e2233da0 100644
--- a/transport.c
+++ b/transport.c
@@ -184,6 +184,7 @@ static int fetch_refs_from_bundle(struct transport *transport,
get_refs_from_bundle_inner(transport);
ret = unbundle(the_repository, &data->header, data->fd,
&extra_index_pack_args, 0);
+ data->fd = -1; /* `unbundle()` closes the file descriptor */
transport->hash_algo = data->header.hash_algo;
return ret;
}
--
2.48.1-293-gbb90fdfe3c
prev parent reply other threads:[~2025-01-26 2:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-25 23:57 [PATCH] bundle: avoid closing file descriptor twice Johannes Schindelin via GitGitGadget
2025-01-26 2:49 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa5bewap7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).