Bug 206339 - fcntl(F_GETLK) still not quite right w/ GFS-kernel-2.6.9-58.3
fcntl(F_GETLK) still not quite right w/ GFS-kernel-2.6.9-58.3
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: GFS-kernel (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Abhijith Das
Dean Jansa
: Reopened
Depends On:
Blocks: 207487 243195
  Show dependency treegraph
 
Reported: 2006-09-13 15:14 EDT by Eric Z. Ayers
Modified: 2010-01-11 22:23 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2006-0705
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-07 15:55:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Source code to reproduce problem with fcntl (F_GETLK) (1.96 KB, text/x-csrc)
2006-09-13 15:14 EDT, Eric Z. Ayers
no flags Details

  None (edit)
Description Eric Z. Ayers 2006-09-13 15:14:25 EDT
Description of problem:

fcntl(F_GETLK) still not quite right w/ GFS-kernel-2.6.9-58.3

It should return F_UNLCK if the lock is held by the process calling fcntl(F_GETLCK)
 

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

GFS-kernel-2.6.9-58.3
kernel-2.6.9-42.0.2.EL

How reproducible:

(Sample source attached)
  
Actual results:

On a GFS partition:

$ /tmp/lock_test2 ./foo
File: "/tmp/lock_test2" locked by:
pid: 24215
type: WRITE
Start: 0x0 Length: 0x64


Expected results:

On an ext3 parition:
$ ./lock_test2 ./foo
No process locking file "./lock_test2"


Additional info:
Comment 1 Eric Z. Ayers 2006-09-13 15:14:25 EDT
Created attachment 136192 [details]
Source code to reproduce problem with fcntl (F_GETLK)
Comment 2 Eric Z. Ayers 2006-09-13 15:16:30 EDT
I've worked with Rob Kenna to get a fix for the fcntl(F_GETLK) working in
RHEL4.3  We've been given a more recent GFS+Kernel that fixes it in most cases
we've tested, but this one is still a problem.
Comment 5 Abhijith Das 2006-09-13 18:21:36 EDT
Created attachment 136217 [details]
patch to fix F_GETLK bug

F_GETLK was passing fl_pid instead of fl_owner to the local_conflict()
function. This function was returning conflicting locks held by the same
process instead of ignoring such locks.
Comment 6 Josef Bacik 2006-09-14 11:27:57 EDT
This looks more to be a bug with VFS, as F_GETLK on ext3 (ext3 doesn't implement
this its actually VFS) should be returning F_WRLCK.  The man page says

"On input to this call, lock describes a lock we would like to place on the
file.  If the lock  could be  placed,  fcntl() does not actually place it, but
returns F_UNLCK in the l_type field of lock and leaves the other fields of the
structure unchanged"

The lock cannot be placed because it is already held, so it returns the value of
the conflicting locks, which in this case is F_WRLCK because that is what we are
trying to do.  Ext3 and every other FS that abdicates to VFS for this function
should be returning F_WRLCK.  If you run the test upstream (FC6) you will see
the same output on ext3 as you see on GFS.
Comment 8 Josef Bacik 2006-09-14 11:41:45 EDT
Well looks like I'm wrong, the PID holding the lock should be able to change the
lock as it desires, so F_GETLK should respond with F_UNLCK for the same pid that
holds the lock.  Sorry for the wild goose chase :(.
Comment 9 Abhijith Das 2006-09-14 12:01:47 EDT
cvs commit -m "fix for bz 206339. Was passing fl_pid instead of fl_owner causing
F_GETLK to return conflicts with a process' own locks" plock.c
Checking in plock.c;
/cvs/cluster/cluster/gfs-kernel/src/dlm/Attic/plock.c,v  <--  plock.c
new revision: 1.12.2.2; previous revision: 1.12.2.1
done
Comment 10 Kiersten (Kerri) Anderson 2006-09-18 12:02:10 EDT
Devel ACK
Comment 16 Red Hat Bugzilla 2006-10-11 12:49:56 EDT
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/RHBA-2006-0705.html
Comment 18 Eric Z. Ayers 2007-06-06 14:35:43 EDT
We are now upgraded to Enterprise 5 but are experiencing the same issue.  
We don't see any relevant ERRATA for Enterprise 5.

 
Comment 19 Rob Kenna 2007-06-07 15:55:13 EDT
I'm re-closing this bug.  This was successfully resolved for Cluster on RHEL
4.5.  I will clone this for RHEL 5, which we can then track.

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