git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Martin Ågren" <martin.agren@gmail.com>
To: git@vger.kernel.org
Cc: "Jeff King" <peff@peff.net>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`
Date: Thu,  5 Oct 2017 22:32:13 +0200	[thread overview]
Message-ID: <b5fc950e4594fb9dec07ec8872c0df8514d149ff.1507228170.git.martin.agren@gmail.com> (raw)
In-Reply-To: <cover.1507228170.git.martin.agren@gmail.com>

If the original version of `write_locked_index()` returned with an
error, it didn't roll back the lockfile unless the error occured at the
very end, during closing/committing. See commit 03b866477 (read-cache:
new API write_locked_index instead of write_index/write_cache,
2014-06-13).

In commit 9f41c7a6b (read-cache: close index.lock in do_write_index,
2017-04-26), we learned to roll back the lock slightly earlier in the
callstack, but that was mostly a side-effect of lockfiles being
implemented using temporary files.

At that point, the behavior was still mostly the same as originally,
except 1) the file was closed (and possibly rolled back) a few
CPU-instructions earlier, and 2) the file was closed even if the caller
didn't ask us to close it. Case 2) is not very interesting since we
never had any such caller and the commit before this one removed the
possibility of asking to leave the lockfile open.

Recently, commit 076aa2cbd (tempfile: auto-allocate tempfiles on heap,
2017-09-05) introduced a subtle bug. If the lockfile is rolled back
(i.e., the temporary file is deleted), the tempfile-pointer in the
`struct lock_file` will be left dangling. Thus, an attempt to reuse the
lockfile, or even just to roll it back, will induce undefined behavior
-- most likely a crash.

Besides not crashing, we clearly want to make things consistent. But
should we roll back always on error, or never? The semantics which the
lockfile-machinery itself provides is A) if we ask to commit and it
fails, roll back, and B) if we ask to close and it fails, do _not_ roll
back.

We should note that commit 83a3069a3 (lockfile: do not rollback lock on
failed close, 2017-09-05) recently changed the behavior for B -- we used
to roll back. We might worry that our callers rely on us rolling back in
case of B. But we only did so for some errors, we never documented
anything, and all our in-tree callers (they are not many) `die()` in
case of an error. This is our opportunity for establishing a consistent
and predictable behavior going forward, so let's enforce the same
semantics that 83a3069a3 introduced to the lockfile-machinery itself.

Similarly, let's ensure that when we are asked to commit, that we always
either commit or roll back. Right now, we have some early return paths
which fail to roll back the lock.

So: Do not delete the temporary file in `do_write_index()`. One of its
callers, `write_locked_index()` will thereby avoid rolling back the
lock. The other caller, `write_shared_index()`, will delete its
temporary file anyway. Both of these callers will avoid undefined
behavior (crashing).

Teach `write_locked_index(..., COMMIT_LOCK)` to roll back the lock
before returning. If we have already succeeded and committed, it will be
a noop. Simplify the existing callers where we now have a superfluous
call to `rollback_lockfile()`. This should keep future readers from
wondering why the callers are inconsistent.

We still close the lock as we close the temporary file. This is what is
referred to as "1)" above. It does feel a bit unfortunate that we simply
"happen" to close the lock by way of an implementation-detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
v2: Except for the slightly different documentation in cache.h, this is
a squash of the last two patches of v1. I hope the commit message is
better.

 builtin/difftool.c |  1 -
 cache.h            |  4 ++++
 merge.c            |  4 +---
 read-cache.c       | 14 ++++++++------
 sequencer.c        |  1 -
 5 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/builtin/difftool.c b/builtin/difftool.c
index b2d3ba753..bcc79d188 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -616,7 +616,6 @@ static int run_dir_diff(const char *extcmd, int symlinks, const char *prefix,
 			if (hold_lock_file_for_update(&lock, buf.buf, 0) < 0 ||
 			    write_locked_index(&wtindex, &lock, COMMIT_LOCK)) {
 				ret = error("could not write %s", buf.buf);
-				rollback_lock_file(&lock);
 				goto finish;
 			}
 			changed_files(&wt_modified, buf.buf, workdir);
diff --git a/cache.h b/cache.h
index 21a6856c5..0e26224b9 100644
--- a/cache.h
+++ b/cache.h
@@ -616,6 +616,10 @@ extern int read_index_unmerged(struct index_state *);
  * split index to the lockfile. If the temporary file for the shared
  * index cannot be created, fall back to the behavior described in
  * the previous paragraph.
+ *
+ * With `COMMIT_LOCK`, the lock is always committed or rolled back.
+ * Without it, the lock is closed, but neither committed nor rolled
+ * back.
  */
 extern int write_locked_index(struct index_state *, struct lock_file *lock, unsigned flags);
 
diff --git a/merge.c b/merge.c
index a18a452b5..e5d796c9f 100644
--- a/merge.c
+++ b/merge.c
@@ -91,9 +91,7 @@ int checkout_fast_forward(const struct object_id *head,
 	}
 	if (unpack_trees(nr_trees, t, &opts))
 		return -1;
-	if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK)) {
-		rollback_lock_file(&lock_file);
+	if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
 		return error(_("unable to write new index file"));
-	}
 	return 0;
 }
diff --git a/read-cache.c b/read-cache.c
index 1c917eba9..0090ab886 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2182,9 +2182,8 @@ static int has_racy_timestamp(struct index_state *istate)
 void update_index_if_able(struct index_state *istate, struct lock_file *lockfile)
 {
 	if ((istate->cache_changed || has_racy_timestamp(istate)) &&
-	    verify_index(istate) &&
-	    write_locked_index(istate, lockfile, COMMIT_LOCK))
-		rollback_lock_file(lockfile);
+	    verify_index(istate))
+		write_locked_index(istate, lockfile, COMMIT_LOCK);
 }
 
 static int do_write_index(struct index_state *istate, struct tempfile *tempfile,
@@ -2314,7 +2313,6 @@ static int do_write_index(struct index_state *istate, struct tempfile *tempfile,
 		return -1;
 	if (close_tempfile_gently(tempfile)) {
 		error(_("could not close '%s'"), tempfile->filename.buf);
-		delete_tempfile(&tempfile);
 		return -1;
 	}
 	if (stat(tempfile->filename.buf, &st))
@@ -2498,7 +2496,8 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
 	    (istate->cache_changed & ~EXTMASK)) {
 		if (si)
 			hashclr(si->base_sha1);
-		return do_write_locked_index(istate, lock, flags);
+		ret = do_write_locked_index(istate, lock, flags);
+		goto out;
 	}
 
 	if (getenv("GIT_TEST_SPLIT_INDEX")) {
@@ -2514,7 +2513,7 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
 	if (new_shared_index) {
 		ret = write_shared_index(istate, lock, flags);
 		if (ret)
-			return ret;
+			goto out;
 	}
 
 	ret = write_split_index(istate, lock, flags);
@@ -2523,6 +2522,9 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
 	if (!ret && !new_shared_index)
 		freshen_shared_index(sha1_to_hex(si->base_sha1), 1);
 
+out:
+	if (flags & COMMIT_LOCK)
+		rollback_lock_file(lock);
 	return ret;
 }
 
diff --git a/sequencer.c b/sequencer.c
index 60636ce54..d56c38081 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1183,7 +1183,6 @@ static int read_and_refresh_cache(struct replay_opts *opts)
 	refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, NULL, NULL, NULL);
 	if (the_index.cache_changed && index_fd >= 0) {
 		if (write_locked_index(&the_index, &index_lock, COMMIT_LOCK)) {
-			rollback_lock_file(&index_lock);
 			return error(_("git %s: failed to refresh the index"),
 				_(action_name(opts)));
 		}
-- 
2.14.2.666.gea220ee40


  parent reply	other threads:[~2017-10-05 20:33 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-01 14:56 [PATCH 00/11] various lockfile-leaks and -fixes Martin Ågren
2017-10-01 14:56 ` [PATCH 01/11] sha1_file: do not leak `lock_file` Martin Ågren
2017-10-02  5:26   ` Jeff King
2017-10-02 10:15     ` Martin Ågren
2017-10-01 14:56 ` [PATCH 02/11] treewide: prefer lockfiles on the stack Martin Ågren
2017-10-02  3:37   ` Junio C Hamano
2017-10-02  4:12     ` Martin Ågren
2017-10-02  5:34   ` Jeff King
2017-10-01 14:56 ` [PATCH 03/11] lockfile: fix documentation on `close_lock_file_gently()` Martin Ågren
2017-10-02  5:35   ` Jeff King
2017-10-01 14:56 ` [PATCH 04/11] tempfile: fix documentation on `delete_tempfile()` Martin Ågren
2017-10-02  5:38   ` Jeff King
2017-10-01 14:56 ` [PATCH 05/11] cache-tree: simplify locking logic Martin Ågren
2017-10-02  3:40   ` Junio C Hamano
2017-10-02  5:41   ` Jeff King
2017-10-01 14:56 ` [PATCH 06/11] apply: move lockfile into `apply_state` Martin Ågren
2017-10-02  5:48   ` Jeff King
2017-10-01 14:56 ` [PATCH 07/11] apply: remove `newfd` from `struct apply_state` Martin Ågren
2017-10-02  5:50   ` Jeff King
2017-10-01 14:56 ` [PATCH 08/11] cache.h: document `write_locked_index()` Martin Ågren
2017-10-01 14:56 ` [PATCH 09/11] read-cache: require flags for `write_locked_index()` Martin Ågren
2017-10-02  3:49   ` Junio C Hamano
2017-10-02  4:14     ` Martin Ågren
2017-10-02 10:16       ` Martin Ågren
2017-10-02  6:00   ` Jeff King
2017-10-01 14:56 ` [PATCH 10/11] read-cache: don't leave dangling pointer in `do_write_index()` Martin Ågren
2017-10-02  6:15   ` Jeff King
2017-10-02  6:20     ` Jeff King
2017-10-01 14:56 ` [PATCH 11/11] read-cache: roll back lock on error with `COMMIT_LOCK` Martin Ågren
2017-10-02  4:01   ` Junio C Hamano
2017-10-02  2:37 ` [PATCH 00/11] various lockfile-leaks and -fixes Junio C Hamano
2017-10-02  6:22 ` Jeff King
2017-10-02  6:30   ` Junio C Hamano
2017-10-02 10:19     ` Martin Ågren
2017-10-03  6:21       ` Junio C Hamano
2017-10-05 20:32         ` [PATCH v2 00/12] " Martin Ågren
2017-10-05 20:32           ` [PATCH v2 01/12] sha1_file: do not leak `lock_file` Martin Ågren
2017-10-06  1:17             ` Junio C Hamano
2017-10-05 20:32           ` [PATCH v2 02/12] treewide: prefer lockfiles on the stack Martin Ågren
2017-10-05 20:32           ` [PATCH v2 03/12] lockfile: fix documentation on `close_lock_file_gently()` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 04/12] tempfile: fix documentation on `delete_tempfile()` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 05/12] checkout-index: simplify locking logic Martin Ågren
2017-10-06  1:21             ` Junio C Hamano
2017-10-05 20:32           ` [PATCH v2 06/12] cache-tree: " Martin Ågren
2017-10-05 20:32           ` [PATCH v2 07/12] apply: move lockfile into `apply_state` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 08/12] apply: remove `newfd` from `struct apply_state` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 09/12] cache.h: document `write_locked_index()` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag Martin Ågren
2017-10-06  1:39             ` Junio C Hamano
2017-10-06 11:02               ` Martin Ågren
2017-10-05 20:32           ` Martin Ågren [this message]
2017-10-06  2:01             ` [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()` Junio C Hamano
2017-10-06 11:04               ` Martin Ågren
2017-10-06 12:02                 ` Junio C Hamano
2017-10-06 19:44                   ` Martin Ågren
2017-10-06 20:12                     ` [PATCH v3 00/12] Re: various lockfile-leaks and -fixes Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 01/12] sha1_file: do not leak `lock_file` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 02/12] treewide: prefer lockfiles on the stack Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 03/12] lockfile: fix documentation on `close_lock_file_gently()` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 04/12] tempfile: fix documentation on `delete_tempfile()` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 05/12] checkout-index: simplify locking logic Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 06/12] cache-tree: " Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 07/12] apply: move lockfile into `apply_state` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 08/12] apply: remove `newfd` from `struct apply_state` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 09/12] cache.h: document `write_locked_index()` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 11/12] read-cache: leave lock in right state in `write_locked_index()` Martin Ågren
2017-10-06 20:12                       ` [PATCH v3 12/12] read_cache: roll back lock in `update_index_if_able()` Martin Ågren
2017-10-05 20:32           ` [PATCH v2 " Martin Ågren

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=b5fc950e4594fb9dec07ec8872c0df8514d149ff.1507228170.git.martin.agren@gmail.com \
    --to=martin.agren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.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.
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).