Bug 1517957

Summary: release can interfere with concurrent acquire
Product: Red Hat Enterprise Linux 7 Reporter: David Teigland <teigland>
Component: sanlockAssignee: David Teigland <teigland>
Status: CLOSED ERRATA QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: agk, cluster-maint, cmarthal, rhandlin
Target Milestone: rcKeywords: FutureFeature, Rebase
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sanlock-3.6.0-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 19:04:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Teigland 2017-11-27 18:14:25 UTC
Description of problem:

There are a couple cases where a host will zero its dblock values on disk: when releasing a lease, and when changing the shared flag in the mode block.  This zeroing was added by commit d6bef45b9716c581d99466280a52a01c9ebe3bf7 without understanding the effect it would have on a concurrent running of a paxos ballot.  This usually happens under fast, repeated attempts by multiple hosts to acquire a lease in both shared and exclusive modes at once.

If a host zeros its own dblock values while other hosts are running a paxos ballot, it can interfere with the paxos algorithm, and cause other hosts to acquire the same version of the lease (lver) that was already acquired.  As far as I can tell, this only happens when releasing the lease from one host, so the effect should not be that multiple hosts are actually using the lease at once, even though technically, hosts holding the same lease version indicates that they are.  So, while the effect may not be severe, this is a severe violation of the algorithm as designed, i.e. that the lease version increments each time it's acquired so that only one host will own a given lease version.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 7 Corey Marthaler 2018-02-27 18:55:11 UTC
Marking this verified with in the current rpms. No sanlock related regressions found in standard testing.

sanlock-3.6.0-1.el7    BUILT: Tue Dec  5 11:47:21 CST 2017
sanlock-lib-3.6.0-1.el7    BUILT: Tue Dec  5 11:47:21 CST 2017


3.10.0-855.el7.x86_64
lvm2-2.02.177-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
lvm2-libs-2.02.177-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
lvm2-cluster-2.02.177-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
lvm2-lockd-2.02.177-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
lvm2-python-boom-0.8.3-2.el7    BUILT: Wed Feb  7 10:42:09 CST 2018
cmirror-2.02.177-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
device-mapper-1.02.146-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
device-mapper-libs-1.02.146-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
device-mapper-event-1.02.146-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
device-mapper-event-libs-1.02.146-4.el7    BUILT: Fri Feb 16 06:22:31 CST 2018
device-mapper-persistent-data-0.7.3-3.el7    BUILT: Tue Nov 14 05:07:18 CST 2017

Comment 10 errata-xmlrpc 2018-04-10 19:04:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1028