D7199: lock: fix race in lock-breaking code

indygreg (Gregory Szorc) phabricator at mercurial-scm.org
Mon Nov 18 23:01:16 EST 2019


This revision is now accepted and ready to land.
indygreg added a comment.
indygreg accepted this revision.


  Thank you for tracking down this issue and for the detailed commit message!
  
  I agree there is a race between 2 processes creating the lock and that we need to verify the created lock once we have it to ensure we "won" the file write race.
  
  FWIW there are known issues with Mercurial's repository locking semantics. I believe we will need to break Mercurial's on-disk file layout to fix all the problems. But (hard-to-debug) issues like the one fixed in this patch do exist and can be fixed without breaking backwards compatibility. If this subject interests you, I suggest reading https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf which chronicles how many popular pieces of software fail to get filesystem consistency correct due to incorrect use of locks, `fsync()`, etc.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7199/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7199

To: valentin.gatienbaron, #hg-reviewers, indygreg
Cc: indygreg, mercurial-devel


More information about the Mercurial-devel mailing list