All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 04/22] rollback_lock_file(): set fd to -1
Date: Sun, 06 Apr 2014 23:45:06 +0200	[thread overview]
Message-ID: <5341CAE2.8040600@alum.mit.edu> (raw)
In-Reply-To: <xmqqtxabwtw8.fsf@gitster.dls.corp.google.com>

On 04/02/2014 06:58 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>> On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote:
>>
>>> When rolling back the lockfile, call close_lock_file() so that the
>>> lock_file's fd field gets set back to -1.  This could help prevent
>>> confusion in the face of hypothetical future programming errors.
>>
>> This also solves a race. We could be in the middle of rollback_lock_file
>> when we get a signal, and double-close. It's probably not a big deal,
>> though, since nobody could have opened a new descriptor in the interim
>> that got the same number (so the second close will just fail silently).
>>
>> Still, this seems like a definite improvement.
> 
> This is probably related to my comments on 2/22, but is "fd" the
> only thing that has a non-zero safe value?  Perhaps lock_file_init()
> that clears the structure fields to 0/NULL and fd to -1, and a
> convenience function lock_file_alloc() that does xmalloc() and then
> calls lock_file_init() may help us a bit when the lockfile structure
> is reused?

The first use of a lock_file object necessarily passes through
lock_file().  The only precondition for that function is that the
on_list field is zero, which is satisfied by a xcalloc()ed object.

Subsequent uses of a lock_file object must *not* zero the object.
lock_file objects are added to the lock_file_list and never removed.  So
zeroing a lock_file object would discard the rest of the linked list.
But subsequent uses must also pass through lock_file(), which sees that
on_list is set, and assumes that the object is in a self-consistent
state as left by commit_lock_file() or rollback_lock_file().

At least that's how it is supposed to work.  But lock_file objects are
in fact not cleaned up correctly in all circumstances.  The next version
of this patch series will work to fix that.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2014-04-06 21:45 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 15:58 [PATCH 00/22] Lockfile refactoring and pre-activation Michael Haggerty
2014-04-01 15:58 ` [PATCH 01/22] t3204: test deleting references when lock files already exist Michael Haggerty
2014-04-01 19:53   ` Jeff King
2014-04-02 10:28     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 02/22] try_merge_strategy(): remove redundant lock_file allocation Michael Haggerty
2014-04-01 19:56   ` Jeff King
2014-04-02 10:53     ` Michael Haggerty
2014-04-02 16:53     ` Junio C Hamano
2014-04-03 12:43       ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 03/22] rollback_lock_file(): do not clear filename redundantly Michael Haggerty
2014-04-01 15:58 ` [PATCH 04/22] rollback_lock_file(): set fd to -1 Michael Haggerty
2014-04-01 19:59   ` Jeff King
2014-04-02 16:58     ` Junio C Hamano
2014-04-06 21:45       ` Michael Haggerty [this message]
2014-04-07 16:37         ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 05/22] lockfile: unlock file if lockfile permissions cannot be adjusted Michael Haggerty
2014-04-01 20:02   ` Jeff King
2014-04-01 20:05     ` Jeff King
2014-04-02  6:47   ` Torsten Bögershausen
2014-04-06 22:02     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 06/22] hold_lock_file_for_append(): release lock on errors Michael Haggerty
2014-04-01 15:58 ` [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list Michael Haggerty
2014-04-01 20:16   ` Jeff King
2014-04-02 17:01     ` Junio C Hamano
2014-04-06 21:54     ` Michael Haggerty
2014-04-07  9:36       ` Jeff King
2014-04-01 15:58 ` [PATCH 08/22] struct lock_file: replace on_list field with flags field Michael Haggerty
2014-04-01 15:58 ` [PATCH 09/22] api-lockfile: expand the documentation Michael Haggerty
2014-04-01 20:19   ` Jeff King
2014-04-02 11:36     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 10/22] lockfile.c: document the various states of lock_file objects Michael Haggerty
2014-04-01 15:58 ` [PATCH 11/22] lockfile: define a constant LOCK_SUFFIX_LEN Michael Haggerty
2014-04-02 17:27   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 12/22] delete_ref_loose(): don't muck around in the lock_file's filename Michael Haggerty
2014-04-01 20:21   ` Jeff King
2014-04-02 11:50     ` Michael Haggerty
2014-04-02  6:52   ` Torsten Bögershausen
2014-04-02  6:55     ` Jeff King
2014-04-01 15:58 ` [PATCH 13/22] config: change write_error() to take a (struct lock_file *) argument Michael Haggerty
2014-04-02  6:58   ` Torsten Bögershausen
2014-04-06 22:04     ` Michael Haggerty
2014-04-02 17:29   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 14/22] lockfile: use strbufs when handling (most) paths Michael Haggerty
2014-04-01 20:28   ` Jeff King
2014-04-02 17:16   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 15/22] resolve_symlink(): use a strbuf internally Michael Haggerty
2014-04-01 15:58 ` [PATCH 16/22] commit_lock_file(): don't work with a fixed-length buffer Michael Haggerty
2014-04-01 15:58 ` [PATCH 17/22] lock_file(): exit early if lockfile cannot be opened Michael Haggerty
2014-04-01 15:58 ` [PATCH 18/22] lockfile: also keep track of the filename of the file being locked Michael Haggerty
2014-04-02 17:19   ` Junio C Hamano
2014-04-06 22:05     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 19/22] struct lock_file: rename lock_filename field to staging_filename Michael Haggerty
2014-04-01 15:58 ` [PATCH 20/22] remove_lock_file(): call rollback_lock_file() Michael Haggerty
2014-04-01 15:58 ` [PATCH 21/22] lockfile: extract a function reset_lock_file() Michael Haggerty
2014-04-02  7:06   ` Eric Sunshine
2014-04-02 13:37     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 22/22] lockfile: allow new file contents to be written while retaining lock Michael Haggerty
2014-04-01 20:39   ` Jeff King
2014-04-02  7:20   ` Eric Sunshine
2014-04-02 17:26   ` Junio C Hamano
2014-04-01 20:44 ` [PATCH 00/22] Lockfile refactoring and pre-activation Jeff King
2014-04-03 11:42   ` Michael Haggerty

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5341CAE2.8040600@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.