Description of problem: Incorrect management of timers failed to be cancelled could lead to crashes when the timer callback is executed and some resources have already been released by the cancelling thread. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: http://review.gluster.org/14712 (cluster/ec: Fix race in timer cancellation) posted (#1) for review on master by Xavier Hernandez (xhernandez)
REVIEW: http://review.gluster.org/14712 (cluster/ec: Fix race in timer cancellation) posted (#2) for review on master by Xavier Hernandez (xhernandez)
REVIEW: http://review.gluster.org/14712 (cluster/ec: Fix race in timer cancellation) posted (#3) for review on master by Xavier Hernandez (xhernandez)
COMMIT: http://review.gluster.org/14712 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit fb013a9db2cc019d36b07644f24e6c15ed39725c Author: Xavier Hernandez <xhernandez> Date: Mon Jun 13 12:42:47 2016 +0200 cluster/ec: Fix race in timer cancellation A race in timer cancellation for delayed unlock could cause a crash if the cancelling thread fails to cancel the timer because it has already been fired but not executed, and the callback is scheduled out of the CPU, delaying it until the thread has released important resources needed by the callback. This patch improves the handling of this case to make it robust. Change-Id: I5c8a8c6610c5136f71b938aa78b5878ba05238d4 BUG: 1345855 Signed-off-by: Xavier Hernandez <xhernandez> Reviewed-on: http://review.gluster.org/14712 Smoke: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu>