threads / discuss / 60882

Race condition in git-bundle(1) create when ref is updated while running

Subject: Race condition in git-bundle(1) create when ref is updated while running

## tl;dr

3 messages between Feb 9, 2024 and Feb 12, 2024.

replies: 2people: 3as markdown or json

Toon Claes· Feb 9, 2024, 13:40 UTC · lore

Hi y'all,

I discovered a bug in git-bundle(1) create. There is a race condition happening when a ref gets updated while the bundle creation process is running.

To reproduce, I've been running git-bundle(1) with `create my.bndl --all --ignore-missing` in a debugger. I've set a breakpoint at bundle.c:515[1] where setup_revisions() is called. After stepping over this line I see in the debugger `revs.pending` is populated.

    (gdb) p *revs.pending.objects
    $6 = {item = 0x7a2fb0, name = 0x78d7e0 "refs/heads/master", path = 0x0, mode = 12288}
    (gdb) p *revs.pending.objects.item
    $7 = {parsed = 1, type = 1, flags = 0, oid = {hash = "R\026\370\365\304\b\236\302\234\344\232\372\024t4\302>\017\001c\000\000\000\000sS\344\367\377\177\000", algo = 1}}

The hash value is the binary representation of `5216f8f5c4089ec29ce49afa147434c23e0f0163`, the current HEAD of `master`. At this point I've updated `master` in another terminal window:

    git commit --allow-empty -m"dummy"

Then in the debugger I continue the process to create the bundle. The resulting bundle seems to be missing `refs/heads/master`.

I'm surprised this ref is completely omitted from the bundle. Even though the ref is outdated, I would expect git-bundle(1) to just take the old commit ID.

[1]: https://github.com/git/git/blob/5216f8f5c4089ec29ce49afa147434c23e0f0163/bundle.c#L515

-- Toon

Junio C Hamano· Feb 9, 2024, 17:39 UTC · re: Toon Claes · lore

Re: Race condition in git-bundle(1) create when ref is updated while running

Toon Claes <toon@iotcl.com> writes:

> I discovered a bug in git-bundle(1) create. There is a race condition
> happening when a ref gets updated while the bundle creation process is
> running.

"--all" that tells "traverse from the tip of all the refs" to any rev-list family of commands (like log and bundle) eventually boils down to opendir("refs/...") followed by readdir(), and if somebody creates or deletes files while you are reading in such a loop, readdir() may appear to skip an entry, which is understandable. Even "git for-each-ref" would race with a ref update (which involves removing a file and then creating another file at the same path), I would think. IOW, I do not think this is limited to "git bundle".

Patrick Steinhardt· Feb 12, 2024, 07:19 UTC · re: Junio C Hamano · lore

Re: Race condition in git-bundle(1) create when ref is updated while running

On Fri, Feb 09, 2024 at 09:39:38AM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Toon Claes <toon@iotcl.com> writes:
> 
> > I discovered a bug in git-bundle(1) create. There is a race condition
> > happening when a ref gets updated while the bundle creation process is
> > running.
> 
> "--all" that tells "traverse from the tip of all the refs" to any
> rev-list family of commands (like log and bundle) eventually boils
> down to opendir("refs/...") followed by readdir(), and if somebody
> creates or deletes files while you are reading in such a loop,
> readdir() may appear to skip an entry, which is understandable.
> Even "git for-each-ref" would race with a ref update (which involves
> removing a file and then creating another file at the same path), I
> would think.  IOW, I do not think this is limited to "git bundle".

Yeah, it's unfortunately a general issue with the "files" backend and nothing that can easily be solved there. The only answer I can provide in this context is that the "reftable" backend will fix it because it enables consistent reads -- sorry for this shameless plug.

Patrick