-
Notifications
You must be signed in to change notification settings - Fork 816
Fix cleanup race condition with exclusive and shared lock files #5319
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.
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
Fix cleanup race condition with exclusive and shared lock files #5319
Conversation
…lusiveLock Signed-off-by: Matthias Schneider <[email protected]>
…redLock Signed-off-by: Matthias Schneider <[email protected]>
850df66
to
109deba
Compare
Note that this PR does NOT address #21861, which deals with files missing from the cleanup procedure. |
I have removed the references to #5308 since this PR deals with a different issue. |
Signed-off-by: Matthias Schneider <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with green CI
Mac failure seems unrelated, going in. |
@Mergifyio backport 3.1.x 2.14.x 2.10.x |
✅ Backports have been created
|
* Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab)
* Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab)
* Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab)
… (#5693) * Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab) Co-authored-by: Matthias Schneider <[email protected]>
… (#5694) * Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab) Co-authored-by: Matthias Schneider <[email protected]>
* Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab)
* Prevent race condition with concurrent cleanup operation in RobustExclusiveLock Signed-off-by: Matthias Schneider <[email protected]> * Prevent race condition with concurrent cleanup operation in RobustSharedLock Signed-off-by: Matthias Schneider <[email protected]> * Adapted coding style as suggested by MiguelCompany Signed-off-by: Matthias Schneider <[email protected]> --------- Signed-off-by: Matthias Schneider <[email protected]> (cherry picked from commit 53bf6ab)
Description
Since on unix file opening and locking are non-atomic operations (open() system call followed with a flock() call), and clean.py depends on exclusive lockability to in order to decide on zombie file deletion, the following race condition (although rare) exists:
RobustExclusiveLock.hpp RobustExclusiveLock::open_and_lock_file calls open() successfully
clean.py opens, successfully locks and deletes the file
RobustExclusiveLock.hpp RobustExclusiveLock::open_and_lock_file calls flock() successfully
This leads to the file's creator assuming a successful file creation (the fd is valid and usable), while in reality the file is not accessible anymore since its directory entry has been removed. A similar situation might be triggered in obustSharedLock.hpp.
Verifying the existence of the directory entry with a call to stat() after successfully obtaining the exclusive lock of the file fixes and restarting the open and lock procedure in case the file was removed in between seems to fix the behavior.
@Mergifyio backport 3.1.x 2.14.x 2.10.x
Contributor Checklist
versions.md
file (if applicable).Reviewer Checklist