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

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

 



On Wed, Mar 13, 2019 at 05:22:22PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > That's what the retry-with-timeout is supposed to address, so maybe it
> > works. But I wouldn't be surprised if it's insufficient in practice,
> > since the reflog code may walk big parts of the graph under lock,
> > checking reachability.
> 
> I suppose this can happen if the reflog for a given branch is so big
> that it takes us more than 100ms to parse it, but e.g. O(n) refs
> shouldn't matter, since we only hold the lock on one ref at a time.

I think it's more than parsing, though.

It's been a while since I've dug into the reflog expiration code, but my
recollection is that it can actually walk parts of the graph (looking
for what's reachable) while processing the reflog. That can be tens of
seconds in decent-sized repositories.

-Peff



[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