[PATCH v3 16/25] commit_lock_file(): die() if called for unlocked lockfile object
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Apr 14, 2014, 13:54 UTC
- Message-ID
- <1397483695-10888-17-git-send-email-mhagger@alum.mit.edu>
- In-Reply-To
- <1397483695-10888-1-git-send-email-mhagger@alum.mit.edu>
It was previously a bug to call commit_lock_file() with a lock_file object that was not active (an illegal access would happen within the function). It was presumably never done, but this would be an easy programming error to overlook. So before continuing, do a consistency check that the lock_file object really is locked.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> --- Documentation/technical/api-lockfile.txt | 4 +++- lockfile.c | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt index b53e300..9a94ead 100644 --- a/Documentation/technical/api-lockfile.txt +++ b/Documentation/technical/api-lockfile.txt @@ -68,7 +68,9 @@ commit_lock_file:: with an earlier call to `hold_lock_file_for_update()`, close the file descriptor and rename the lockfile to its final destination. Returns 0 upon success, a negative - value on failure to close(2) or rename(2). + value on failure to close(2) or rename(2). It is a bug to + call `commit_lock_file()` for a `lock_file` object that is not + currently locked. rollback_lock_file:: diff --git a/lockfile.c b/lockfile.c index 664b0c3..1453a7a 100644 --- a/lockfile.c +++ b/lockfile.c @@ -292,6 +292,9 @@ int commit_lock_file(struct lock_file *lk) if (lk->fd >= 0 && close_lock_file(lk)) return -1; + if (!lk->filename[0]) + die("BUG: attempt to commit unlocked object"); + strcpy(result_file, lk->filename); /* remove ".lock": */ result_file[strlen(result_file) - LOCK_SUFFIX_LEN] = 0;
-- 1.9.1