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