git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v7 24/38] struct lock_file: declare some fields volatile

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Oct 1, 2014, 10:28 UTC
Message-ID
<1412159322-2622-25-git-send-email-mhagger@alum.mit.edu>
In-Reply-To
<1412159322-2622-1-git-send-email-mhagger@alum.mit.edu>

The function remove_lock_file_on_signal() is used as a signal handler. It is not realistic to make the signal handler conform strictly to the C standard, which is very restrictive about what a signal handler is allowed to do. But let's increase the likelihood that it will work:

The lock_file_list global variable and several fields from struct lock_file are used by the signal handler. Declare those values "volatile" to (1) force the main process to write the values to RAM promptly, and (2) prevent updates to these fields from being reordered in a way that leaves an opportunity for a jump to the signal handler while the object is in an inconsistent state.

We don't mark the filename field volatile because that would prevent the use of strcpy(), and it is anyway unlikely that a compiler re-orders a strcpy() call across other expressions. So in practice it should be possible to get away without "volatile" in the "filename" case.

Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 cache.h    | 6 +++---
 lockfile.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 8e25fce..c2ea6f1 100644
--- a/cache.h
+++ b/cache.h
@@ -575,10 +575,10 @@ extern int refresh_index(struct index_state *, unsigned int flags, const struct
 #define LOCK_SUFFIX_LEN 5
 
 struct lock_file {
-	struct lock_file *next;
+	struct lock_file *volatile next;
 	volatile sig_atomic_t active;
-	int fd;
-	pid_t owner;
+	volatile int fd;
+	volatile pid_t owner;
 	char on_list;
 	char filename[PATH_MAX];
 };
diff --git a/lockfile.c b/lockfile.c
index d35ac44..89043f5 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -55,7 +55,7 @@
  *     on_list is set.
  */
 
-static struct lock_file *lock_file_list;
+static struct lock_file *volatile lock_file_list;
 
 static void remove_lock_file(void)
 {
-- 
2.1.0
Previous: Michael HaggertyNext: Michael Haggerty
Message 28 of 43 in “Lockfile correctness and refactoring”
  1. 00/38 Lockfile correctness and refactoringMichael Haggerty, Oct 1, 2014
  2. 01/38 unable_to_lock_die(): rename function from unable_to_lock_index_die()Michael Haggerty, Oct 1, 2014
  3. 02/38 api-lockfile: revise and expand the documentationMichael Haggerty, Oct 1, 2014
  4. 03/38 close_lock_file(): exit (successfully) if file is already closedMichael Haggerty, Oct 1, 2014
  5. 04/38 rollback_lock_file(): do not clear filename redundantlyMichael Haggerty, Oct 1, 2014
  6. 05/38 rollback_lock_file(): exit early if lock is not activeMichael Haggerty, Oct 1, 2014
  7. 06/38 rollback_lock_file(): set fd to -1Michael Haggerty, Oct 1, 2014
  8. 07/38 lockfile: unlock file if lockfile permissions cannot be adjustedMichael Haggerty, Oct 1, 2014
  9. 08/38 hold_lock_file_for_append(): release lock on errorsMichael Haggerty, Oct 1, 2014
  10. 09/38 lock_file(): always initialize and register lock_file objectMichael Haggerty, Oct 1, 2014
  11. René ScharfeOct 1, 2014
  12. Michael HaggertyOct 1, 2014
  13. Junio C HamanoOct 1, 2014
  14. 10/38 lockfile.c: document the various states of lock_file objectsMichael Haggerty, Oct 1, 2014
  15. 11/38 cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LENMichael Haggerty, Oct 1, 2014
  16. 12/38 delete_ref_loose(): don't muck around in the lock_file's filenameMichael Haggerty, Oct 1, 2014
  17. 13/38 prepare_index(): declare return value to be (const char *)Michael Haggerty, Oct 1, 2014
  18. 14/38 lock_file(): exit early if lockfile cannot be openedMichael Haggerty, Oct 1, 2014
  19. 15/38 remove_lock_file(): call rollback_lock_file()Michael Haggerty, Oct 1, 2014
  20. 16/38 commit_lock_file(): inline temporary variableMichael Haggerty, Oct 1, 2014
  21. 17/38 commit_lock_file(): die() if called for unlocked lockfile objectMichael Haggerty, Oct 1, 2014
  22. 18/38 close_lock_file(): if close fails, roll backMichael Haggerty, Oct 1, 2014
  23. 19/38 commit_lock_file(): rollback lock file on failure to renameMichael Haggerty, Oct 1, 2014
  24. 20/38 api-lockfile: document edge casesMichael Haggerty, Oct 1, 2014
  25. 21/38 dump_marks(): remove a redundant call to rollback_lock_file()Michael Haggerty, Oct 1, 2014
  26. 22/38 git_config_set_multivar_in_file(): avoid call to rollback_lock_file()Michael Haggerty, Oct 1, 2014
  27. 23/38 lockfile: avoid transitory invalid statesMichael Haggerty, Oct 1, 2014
  28. 24/38 struct lock_file: declare some fields volatileMichael Haggerty, Oct 1, 2014
  29. 25/38 try_merge_strategy(): remove redundant lock_file allocationMichael Haggerty, Oct 1, 2014
  30. 26/38 try_merge_strategy(): use a statically-allocated lock_file objectMichael Haggerty, Oct 1, 2014
  31. 27/38 commit_lock_file(): use a strbuf to manage temporary spaceMichael Haggerty, Oct 1, 2014
  32. 28/38 Change lock_file::filename into a strbufMichael Haggerty, Oct 1, 2014
  33. 29/38 resolve_symlink(): use a strbuf for internal scratch spaceMichael Haggerty, Oct 1, 2014
  34. 30/38 resolve_symlink(): take a strbuf parameterMichael Haggerty, Oct 1, 2014
  35. 31/38 trim_last_path_component(): replace last_path_elm()Michael Haggerty, Oct 1, 2014
  36. 32/38 Extract a function commit_lock_file_to()Michael Haggerty, Oct 1, 2014
  37. 33/38 Rename LOCK_NODEREF to LOCK_NO_DEREFMichael Haggerty, Oct 1, 2014
  38. 34/38 lockfile.c: rename static functionsMichael Haggerty, Oct 1, 2014
  39. 35/38 get_locked_file_path(): new functionMichael Haggerty, Oct 1, 2014
  40. 36/38 hold_lock_file_for_append(): restore errno before returningMichael Haggerty, Oct 1, 2014
  41. 37/38 Move read_index() definition to read-cache.cMichael Haggerty, Oct 1, 2014
  42. 38/38 lockfile.h: extract new header file for the functions in lockfile.cMichael Haggerty, Oct 1, 2014
  43. Junio C HamanoOct 1, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.