public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: Michael Haggerty <mhagger@alum•mit.edu>, git@vger•kernel.org
Subject: Re: [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list
Date: Wed, 02 Apr 2014 10:01:59 -0700	[thread overview]
Message-ID: <xmqqppkzwtq0.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140401201659.GE21715@sigill.intra.peff.net> (Jeff King's message of "Tue, 1 Apr 2014 16:16:59 -0400")

Jeff King <peff@peff•net> writes:

> So for a moment, lk->filename contains the name of the valuable file we
> are locking.  If we get a signal at that moment, do we accidentally
> delete it in remove_lock_file?
>
> I think the answer is "no", because we check lk->owner before deleting,
> which will not match our pid (it should generally be zero due to xcalloc
> or static initialization, though perhaps we should clear it here).

That "generally be zero" no longer holds since 2/22, no?

> But that makes me wonder about the case of a reused lock. It will have
> lk->owner set from a previous invocation, and would potentially suffer
> from this problem. In other words, I think the change you are
> introducing does not have the problem, but the existing code does. :-/

Yes, I tend to agree.

> I didn't reproduce it experimentally, though.  We should be able to just
>
>     lk->owner = 0;
>
> before the initial strcpy to fix it, I would think.
>
> -Peff

  reply	other threads:[~2014-04-03 10:01 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
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 [this message]
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=xmqqppkzwtq0.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=mhagger@alum$(echo .)mit.edu \
    --cc=peff@peff$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox