Bug #43589
closedPotential live-lock in disable/enable feature request
0%
Description
For example, if a disable journal feature request is received by a lock owner, the DisableFeaturesRequest state machine will start "ImageState::prepare_lock" which will prevent future image state updates (like image refreshes) until the prepare lock step is completed. However, if a header update notification is received while in this state, the DisableFeaturesRequest state machine will attempt to disable mirroring which involves a refresh image step. This will live-lock and the state machines will never advance. It seems the simple solution would be to extract the refresh step from the librbd::mirror::GetInfoRequest state machine and instead move the refresh to the API callers.
Updated by Mykola Golub over 4 years ago
- Status changed from New to Fix Under Review
- Pull request ID set to 32734
Updated by Jason Dillaman about 4 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Nathan Cutler about 4 years ago
- Copied to Backport #43829: mimic: Potential live-lock in disable/enable feature request added
Updated by Nathan Cutler about 4 years ago
- Copied to Backport #43830: nautilus: Potential live-lock in disable/enable feature request added
Updated by Nathan Cutler about 4 years ago
- Copied to Backport #43831: luminous: Potential live-lock in disable/enable feature request added
Updated by Nathan Cutler about 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".