From: Jeff King <peff@peff.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Junio C Hamano <gitster@pobox.com>,
Johan Herland <johan@herland.net>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
git@vger.kernel.org
Subject: Re: [PATCH v2 00/12] Fix some reference-related races
Date: Thu, 20 Jun 2013 07:52:22 -0400 [thread overview]
Message-ID: <20130620115221.GA773@sigill.intra.peff.net> (raw)
In-Reply-To: <51C2C6DD.90107@alum.mit.edu>
On Thu, Jun 20, 2013 at 11:09:49AM +0200, Michael Haggerty wrote:
> 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.
>
> [...]
>
> 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).
Yeah, I agree. You could also "roll back" the loose deletion, but I'd
rather just try to do it atomically.
I don't think this increases lock contention, since delete_ref would
need to lock the packed-refs file anyway. However, there is the related
change that we should probably lock the packed-refs file before checking
"is this ref in the packed-refs file?" in repack_without_ref. Which does
increase lock contention, but is more correct.
We should also consider deadlock issues. If the order is always "acquire
packed-refs lock, then acquire loose locks", we are fine. If this does
loose-then-packed, we are also fine with the current code, as
git-pack-refs does not prune the loose refs while under the packed-refs
lock. But I seem to recall discussion of pruning them under the
packed-refs lock, which would deadlock if repack_without_ref does
loose-then-packed.
But I guess we do not actually block on locks, but rather just die (and
release our locks), so deadlock is not an option for us.
-Peff
prev parent reply other threads:[~2013-06-20 11:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 7:51 [PATCH v2 00/12] Fix some reference-related races Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 01/12] repack_without_ref(): split list curation and entry writing Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 02/12] pack_refs(): split creation of packed refs " Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 03/12] refs: wrap the packed refs cache in a level of indirection Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 04/12] refs: implement simple transactions for the packed-refs file Michael Haggerty
2013-06-19 19:18 ` Junio C Hamano
2013-06-20 7:49 ` Michael Haggerty
2013-06-20 11:55 ` Jeff King
2013-06-20 18:03 ` Michael Haggerty
2013-06-20 19:55 ` Jeff King
2013-06-20 17:11 ` Junio C Hamano
2013-06-20 17:58 ` Michael Haggerty
2013-06-20 18:36 ` Junio C Hamano
2013-06-19 7:51 ` [PATCH v2 05/12] refs: manage lifetime of packed refs cache via reference counting Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 06/12] do_for_each_entry(): increment the packed refs cache refcount Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 07/12] packed_ref_cache: increment refcount when locked Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 08/12] Extract a struct stat_data from cache_entry Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 09/12] add a stat_validity struct Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 10/12] get_packed_ref_cache: reload packed-refs file when it changes Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 11/12] for_each_ref: load all loose refs before packed refs Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 12/12] refs: do not invalidate the packed-refs cache unnecessarily Michael Haggerty
2013-06-19 18:56 ` [PATCH v2 00/12] Fix some reference-related races Jeff King
2013-06-20 9:09 ` Michael Haggerty
2013-06-20 11:52 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130620115221.GA773@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=mhagger@alum.mit.edu \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).