Re: BUG: Race condition due to reflog expiry in "gc"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> I'm still working on fixing a race condition I encountered in "gc"
> recently, but am not 100% sure of the fix. So I thought I'd send a
> braindump of what I have so far in case it jolts any memories.
>
> The problem is that when we "gc" we run "reflog expire --all". This
> iterates over the reflogs, and takes a *.lock for each reference.
>
> It'll fail intermittendly in two ways:
>
>  1. If something is concurrently committing to the repo it'll fail
>     because we for a tiny amount of time hold a HEAD.lock file, so HEAD
>     can't be updated.
>
>  2. On a repository that's just being "git fetch"'d by some concurrent
>     process the "gc" will fail, because the ref's SHA1 has changed,
>     which we inspect as we aquire the lock.

Both sounds very much expected and expectable outcome.  I am not
sure how they need to be called bugs.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux