Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix possible race condition in lockers with session expiration #34

Closed
eric opened this issue May 23, 2012 · 0 comments
Closed

Fix possible race condition in lockers with session expiration #34

eric opened this issue May 23, 2012 · 0 comments

Comments

@eric
Copy link
Member

eric commented May 23, 2012

Right now it's possible for a locker to unlock a lock it didn't actually create:

  • client1 grab lock lock
  • client2 try to grab lock and wait
  • client1 session expires (lock released)
  • client2 gets lock
  • client2 releases lock and deletes parent
  • client3 grabs lock and creates parent
  • client1 has reconnected and releases lock (it didn't create)

The solution we've come up with is to track the ctime of the parent and only delete the lock if the ctime of the parent matches what we thought it was.

The reason why this works is if the parent hasn't been deleted, the sequence numbers of the lock files will always be increasing.
slyphon added a commit that referenced this issue May 24, 2012
@slyphon
implement the fix for #34
e3939ef 
when lock path is created, we now cache the stat of the parent at that time,
allowing us to compare ctimes when we want to clean up. an unlock call on a
lock not owned by the current session will return false now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eric @slyphon