Bug 160844 - dangling POSIX locks after close
dangling POSIX locks after close
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
: Regression
Depends On:
Blocks: 168429
  Show dependency treegraph
 
Reported: 2005-06-17 15:01 EDT by Peter Staubach
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2006-0132
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 14:09:20 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)
Test program to reproduce the situation. (3.32 KB, text/plain)
2005-06-17 15:03 EDT, Peter Staubach
no flags Details
Proposed patch (5.36 KB, patch)
2005-06-29 09:40 EDT, Peter Staubach
no flags Details | Diff
Proposed patch (5.32 KB, patch)
2005-07-27 15:36 EDT, Peter Staubach
no flags Details | Diff

  None (edit)
Description Peter Staubach 2005-06-17 15:01:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050416 Red Hat/1.0.3-1.4.1 Firefox/1.0.3

Description of problem:
There is a race between fcntl and close which can result in orphanned POSIX
locks.  In general, these races are handled via the support to remove locks
when the last reference to an open file is released.  Sometimes, this does
not occur in a timely fashion and could cause problems.  This can happen
because an application was holding a reference to an open file, which would
delay the last reference to an open file being released.

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


How reproducible:
Always

Steps to Reproduce:
1. Compile and run the attach test program.


Actual Results:  The test program attempts to lock what should be a completely unlocked file.
The lock attempt fails because there is a lock outstanding on the file, long
after it should have been released.

Expected Results:  The lock attempt made in the test program should succeed.

Additional info:

This bug has already been fixed in RHEL 3 U6.  The problem continues to exist
in RHEL 4, although not with the same severity.
Comment 1 Peter Staubach 2005-06-17 15:03:52 EDT
Created attachment 115635 [details]
Test program to reproduce the situation.
Comment 2 Peter Staubach 2005-06-17 15:05:42 EDT
The test program should be run with a "delay" argument of at least 30 seconds.
This is due to some issue with the multithreading on RHEL 4 which I've not
looked into yet.
Comment 3 Peter Staubach 2005-06-29 09:40:58 EDT
Created attachment 116125 [details]
Proposed patch
Comment 4 Peter Staubach 2005-06-29 09:41:53 EDT
A patch containing these changes has been accepted upstream into the '-mm'
release.
Comment 6 Peter Staubach 2005-07-27 15:36:22 EDT
Created attachment 117209 [details]
Proposed patch
Comment 7 Peter Staubach 2005-07-27 15:38:23 EDT
The proposed patch was sent upstream.  After review, it was simplified very
slightly and has been sent to Linus for inclusion into his kernel.
Comment 12 Red Hat Bugzilla 2006-03-07 14:09:20 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0132.html

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