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.
Helped-by: Johannes Sixt <j6t@xxxxxxxx>
Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
---
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 9e1cdd2..6436111 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -312,6 +312,9 @@ int commit_lock_file(struct lock_file *lk)
{
char result_file[PATH_MAX];
+ if (!lk->filename[0])
+ die("BUG: attempt to commit unlocked object");
+
if (lk->fd >= 0 && close_lock_file(lk))
return -1;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html