Re: [PATCH v3 7/9] refs/files: detect race when generating reflog entry for HEAD

From: Toon Claes <toon@iotcl.com>
Date: Aug 1, 2025, 11:55 UTC
Message-ID: <87seibuuh8.fsf@iotcl.com>
In-Reply-To: <20250729-pks-reflog-append-v3-7-9614d310f073@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 19 quoted lines

> When updating a reference that is being pointed to HEAD we don't only
> write a reflog message for that particular reference, but also generate
> one for HEAD. This logic is handled by `split_head_update()`, where we:
>
>   1. Verify that the condition actually triggered. This is done by
>      reading HEAD at the start of the transaction so that we can then
>      check whether a given reference update refers to its target.
>
>   2. Queue a new log-only update for HEAD in case it did.
>
> But the logic is unfortunately not free of races, as we do not lock the
> HEAD reference after we have read its target. This can lead to the
> following two scenarios:
>
>   - HEAD gets concurrently updated to point to one of the references we
>     have already processed. This causes us not writing a reflog message
>     even though we should have done so.
>
>   - HEAD gets concurrently updated to point to not point to a reference

That's a little much of pointing, right? ;)

Maybe change it to something like:

    - HEAD gets concurrently updated to no longer point to a reference

-- 
Cheers,
Toon