Bug 1288638

Summary:	sanlock shared leases are erased on disk
Product:	Red Hat Enterprise Linux 7	Reporter:	David Teigland <teigland>
Component:	sanlock	Assignee:	David Teigland <teigland>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Aharon Canan <acanan>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	acanan, agk, amureini, cluster-maint, cmarthal, nsoffer
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-29 13:58:01 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:
Bug Depends On:
Bug Blocks:	1295577, 1313485

Description David Teigland 2015-12-04 20:20:25 UTC

Description of problem:

This is a regression in 7.2 that breaks the protection of leases when the shared lease mode is used.  It first appeared in sanlock 3.2.3, as a result of this commit:

https://git.fedorahosted.org/cgit/sanlock.git/commit/?id=e40e1f6e22f9b10f08d53fc7

That commit added a paxos_erase_dblock() call in paxos_lease_release(), which wrongly clears the shared flag in the mode_block that had just been set.  Acquiring the shared lease works, and sanlock believes it is held, but on disk the shared flag has been inadvertently cleared by erasing the dblock structure.  This means that an exclusive lease requested by another host will not see the shared flag and will succeed.

Two hosts will never be able to hold an exclusive lease concurrently, and an existing exclusive lease can never be acquired shared by another host.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Teigland 2015-12-04 20:31:45 UTC

fix is here
https://git.fedorahosted.org/cgit/sanlock.git/commit/?id=ce98f5f8141bdf012caf40046dab7fa69f433fdf

Comment 2 David Teigland 2016-01-19 15:37:56 UTC

This will be part of the sanlock rebase, bug 1295876.

Comment 4 Aharon Canan 2016-09-29 13:58:01 UTC

We (Rhev storage QE) executed our automation using below sanlock pkgs and didn't face anything special.

[root@lynx09 ~]# rpm -qa |grep sanlock
sanlock-lib-3.4.0-1.el7.x86_64
sanlock-3.4.0-1.el7.x86_64
libvirt-lock-sanlock-2.0.0-10.el7.x86_64
sanlock-python-3.4.0-1.el7.x86_64


Closing.