Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517957 - release can interfere with concurrent acquire
Summary: release can interfere with concurrent acquire
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sanlock
Version: 7.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-27 18:14 UTC by David Teigland
Modified: 2018-04-10 19:04 UTC (History)
4 users (show)

Fixed In Version: sanlock-3.6.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-04-10 19:04:15 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1028 None None None 2018-04-10 19:04:18 UTC

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:

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

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.

Note You need to log in before you can comment on or make changes to this bug.