On 06/19/2013 08:56 PM, Jeff King wrote:
> On Wed, Jun 19, 2013 at 09:51:21AM +0200, Michael Haggerty wrote:
>> Re-roll of mh/ref-races.  Thanks to Peff, Junio, and Ramsay for
>> reviewing v1.
> Thanks. I just read through them again. Everything looks good to me.
> Patches 10 and 11 are missing my signoff, but obviously:
>   Signed-off-by: Jeff King <p...@peff.net>
>> The last patch is still optional--it avoids a little bit of work when
>> rewriting the packed-refs file, but relies on the stat-based freshness
>> check not giving a false negative.
> I don't have a real problem with it, but given the cygwin confusions
> that Ramsay mentioned, maybe it is better to hold back on it for now? It
> sounds like the cygwin problems go the other way (false positives
> instead of false negatives).

I just realized that there is another long-standing problem in
loose/packed refs handling:

Suppose there is a loose reference for which an old version is still
present in the packed-refs file.  If the reference is deleted:

1. delete_ref() gets a lock on the loose reference file

2. delete_ref() deletes the loose reference file while retaining the lock

3. delete_ref() calls repack_without_ref()

4. repack_without_ref() tries to acquire a lock on the packed-refs file
to delete the packed version of the reference.

If the packed-refs file is already locked by another process (and there
is no reason why that cannot be, and there is only one attempt to
acquire the lock), then repack_without_ref() emits an error and returns
with an error code.  delete_ref() passes the error along, but doesn't
restore the loose ref.

The net result is that an old version of the ref (namely the one in the
loose refs file) has been revived.  That version might even point at an
object that has already been garbage collected.

This problem is similar to race conditions that have been discussed
earlier, but this problem has nothing to do with the freshness/staleness
of the packed-refs file WRT to the loose reference; it only depends on
the packed-refs file being locked by another process at an inopportune time.

I think this problem would also be fixed by the locking scheme that I
proposed earlier [1]: to acquire and hold the packed-refs lock across
the modification of *both* files, and to rewrite the packed-refs file
*before* deleting the loose-refs file (because rewriting the packed-refs
file without the to-be-deleted reference is a logical NOP).


[1] http://article.gmane.org/gmane.comp.version-control.git/212131

Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to