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

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

[Toon Claes]

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

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

[Junio C Hamano]

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".

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Fri, Feb 09, 2024 at 09:39:38AM -0800, Junio C Hamano wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]