From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Torsten Bögershausen" <tboegi@web.de>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: [PATCH v2 07/25] lock_file(): always add lock_file object to lock_file_list
Date: Mon, 7 Apr 2014 01:33:49 +0200 [thread overview]
Message-ID: <1396827247-28465-8-git-send-email-mhagger@alum.mit.edu> (raw)
In-Reply-To: <1396827247-28465-1-git-send-email-mhagger@alum.mit.edu>
It used to be that if locking failed, lock_file() usually did not
register the lock_file object in lock_file_list but sometimes it did.
This confusion was compounded if lock_file() was called via
hold_lock_file_for_append(), which has its own failure modes.
The ambiguity didn't have any ill effects, because lock_file objects
cannot be removed from the lock_file_list anyway. But it is
unnecessary to leave this behavior inconsistent.
So change lock_file() to *always* ensure that the lock_file object is
registered in lock_file_list regardless of whether an error occurs.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
lockfile.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index e78a35f..120a6d6 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
*/
static const size_t max_path_len = sizeof(lk->filename) - 5;
+ if (!lock_file_list) {
+ /* One-time initialization */
+ sigchain_push_common(remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
+
+ if (!lk->on_list) {
+ /* Initialize *lk and add it to lock_file_list: */
+ lk->fd = -1;
+ lk->owner = 0;
+ lk->on_list = 1;
+ lk->filename[0] = 0;
+ lk->next = lock_file_list;
+ lock_file_list = lk;
+ }
+
if (strlen(path) >= max_path_len)
return -1;
strcpy(lk->filename, path);
@@ -138,16 +154,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
strcat(lk->filename, ".lock");
lk->fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= lk->fd) {
- if (!lock_file_list) {
- sigchain_push_common(remove_lock_file_on_signal);
- atexit(remove_lock_file);
- }
lk->owner = getpid();
- if (!lk->on_list) {
- lk->next = lock_file_list;
- lock_file_list = lk;
- lk->on_list = 1;
- }
if (adjust_shared_perm(lk->filename)) {
error("cannot fix permission bits on %s", lk->filename);
rollback_lock_file(lk);
--
1.9.1
next prev parent reply other threads:[~2014-04-06 23:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 23:33 [PATCH v2 00/25] Lockfile correctness and refactoring Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 01/25] api-lockfile: expand the documentation Michael Haggerty
2014-04-07 18:46 ` Jeff King
2014-04-06 23:33 ` [PATCH v2 02/25] unable_to_lock_die(): rename function from unable_to_lock_index_die() Michael Haggerty
2014-04-07 18:47 ` Jeff King
2014-04-08 14:04 ` Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 03/25] rollback_lock_file(): do not clear filename redundantly Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 04/25] rollback_lock_file(): set fd to -1 Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 05/25] lockfile: unlock file if lockfile permissions cannot be adjusted Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 06/25] hold_lock_file_for_append(): release lock on errors Michael Haggerty
2014-04-06 23:33 ` Michael Haggerty [this message]
2014-04-06 23:33 ` [PATCH v2 08/25] struct lock_file: replace on_list field with flags field Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 09/25] lockfile.c: document the various states of lock_file objects Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 10/25] lockfile: define a constant LOCK_SUFFIX_LEN Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 11/25] delete_ref_loose(): don't muck around in the lock_file's filename Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 12/25] prepare_index(): declare return value to be (const char *) Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 13/25] write_packed_entry_fn(): convert cb_data into a (const int *) Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 14/25] lock_file(): exit early if lockfile cannot be opened Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 15/25] remove_lock_file(): call rollback_lock_file() Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 16/25] commit_lock_file(): inline temporary variable Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 17/25] commit_lock_file(): make committing an unlocked lockfile a NOP Michael Haggerty
2014-04-07 19:31 ` Jeff King
2014-04-14 8:21 ` Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 18/25] lockfile: avoid transitory invalid states Michael Haggerty
2014-04-07 6:16 ` Johannes Sixt
2014-04-07 11:13 ` Michael Haggerty
2014-04-07 12:12 ` Johannes Sixt
2014-04-07 13:12 ` Michael Haggerty
2014-04-07 19:38 ` Jeff King
2014-04-06 23:34 ` [PATCH v2 19/25] try_merge_strategy(): remove redundant lock_file allocation Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 20/25] try_merge_strategy(): use a statically-allocated lock_file object Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 21/25] commit_lock_file(): use a strbuf to manage temporary space Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 22/25] Change lock_file::filename into a strbuf Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 23/25] resolve_symlink(): use a strbuf for internal scratch space Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 24/25] resolve_symlink(): take a strbuf parameter Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 25/25] trim_last_path_elm(): replace last_path_elm() Michael Haggerty
2014-04-07 19:40 ` [PATCH v2 00/25] Lockfile correctness and refactoring Jeff King
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=1396827247-28465-8-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
--cc=tboegi@web.de \
/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 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 NNTP newsgroup(s).