This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1288638 - sanlock shared leases are erased on disk
sanlock shared leases are erased on disk
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sanlock (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: David Teigland
Aharon Canan
:
Depends On:
Blocks: 1313485 1295577
  Show dependency treegraph
 
Reported: 2015-12-04 15:20 EST by David Teigland
Modified: 2016-09-29 09:58 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-29 09:58:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Teigland 2015-12-04 15:20:25 EST
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 2 David Teigland 2016-01-19 10:37:56 EST
This will be part of the sanlock rebase, bug 1295876.
Comment 4 Aharon Canan 2016-09-29 09:58:01 EDT
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.

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