Bug 146479 - pids with held posix locks on gfs/gulm didn't drop on signals.
pids with held posix locks on gfs/gulm didn't drop on signals.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gulm (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-28 13:30 EST by michael conrad tadpol tilstra
Modified: 2010-01-04 14:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-04 14:06:44 EST
Type: ---
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 michael conrad tadpol tilstra 2005-01-28 13:30:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Description of problem:
if a pid on gfs was holding posix range locks and the process died from a signal, the posix range lock was not released.  Later, other processes that might try to get the same lock would fail or block forever.  A cluster reset was required to get out of this.

Version-Release number of selected component (if applicable):
cvs head and rhel4 branch

How reproducible:
Always

Steps to Reproduce:
plock, kill, damn.

Additional info:
Comment 1 michael conrad tadpol tilstra 2005-01-28 13:43:54 EST
Easy enough fix.  actually just had the state inverted.  Wasn't calling the
upside posix lock update function when I should have been.  Do that right, and
this bug is gone.
Comment 2 Lon Hohberger 2010-01-04 14:06:44 EST
I believe this was fixed about 5 years ago, but was never added to any erratum.

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