Bug 206590 - fcntl(F_UNLCK) return code
fcntl(F_UNLCK) return code
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: dlm (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Abhijith Das
Cluster QE
:
Depends On:
Blocks: 207487
  Show dependency treegraph
 
Reported: 2006-09-15 01:57 EDT by Wendy Cheng
Modified: 2009-04-16 15:55 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2006-0705
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-11 12:50:35 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)
test case supplied by support front end engineer (Piyush Yaduvanshi) (621 bytes, text/plain)
2006-09-15 02:04 EDT, Wendy Cheng
no flags Details
fix to the bug (593 bytes, patch)
2006-09-15 12:11 EDT, Abhijith Das
no flags Details | Diff

  None (edit)
Description Wendy Cheng 2006-09-15 01:57:15 EDT
Description of problem:
"man 2 fcntl" says:

 F_SETLK
  Acquire a lock (when l_type is F_RDLCK or F_WRLCK) or release a
  lock (when l_type is F_UNLCK) on the  bytes  specified  by  the
  l_whence,  l_start, and l_len fields of lock.  If a conflicting
  lock is held by another process, this call returns -1 and  sets
  errno to EACCES or EAGAIN.

Look like customer expects "-1" is returned "only" when there are
conflicts. They probably use this return code to decide whether the
file has locks and do things accordingly. And this is exactly what
linux VFS layer does (i.e., when there is no owner, fcntl(F_UNLCK)
return 0.

In GFS case, if the lock doesn't have owner fcntl(F_UNLCK) return -1.
Test case will be attached.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Wendy Cheng 2006-09-15 02:04:04 EDT
Created attachment 136330 [details]
test case supplied by support front end engineer (Piyush Yaduvanshi)
Comment 2 Wendy Cheng 2006-09-15 02:15:09 EDT
I did a quick browsing thru plock code. Look like an easy fix - just add a check
into punlock_internal() and unconditionally with "0" if that is true. Your call
though.

If you want me to hack the patch, let me know.
Comment 3 Wendy Cheng 2006-09-15 02:17:21 EDT
sorry, s/unconditionally with/unconditionally return/ in above update. 
Comment 4 Abhijith Das 2006-09-15 12:11:56 EDT
Created attachment 136370 [details]
fix to the bug

It has nothing to do with punlock_internal(), actually. The call to
get_resource() in lm_dlm_punlock() returns -ENOENT because it cannot find any
plocks associated with the given inode. This patch checks for -ENOENT return
code and returns 0 in the case of F_UNLCK. Wendy/Dave, please let me know if
this makes sense and if it's ok to commit.
Comment 5 Wendy Cheng 2006-09-15 12:26:01 EDT
Looks good to me.
Comment 6 Abhijith Das 2006-09-15 13:44:35 EDT
cvs commit -m "fix for bz 206590. F_UNLCK was returning -ENOENT when it didn't
find plocks associated with the given inode. Should return 0 now." plock.c
Checking in plock.c;
/cvs/cluster/cluster/gfs-kernel/src/dlm/Attic/plock.c,v  <--  plock.c
new revision: 1.12.8.3; previous revision: 1.12.8.2
done
Comment 9 Red Hat Bugzilla 2006-10-11 12:50:35 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

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