Bug 206590

Summary: fcntl(F_UNLCK) return code
Product: [Retired] Red Hat Cluster Suite Reporter: Wendy Cheng <nobody+wcheng>
Component: dlmAssignee: Abhijith Das <adas>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: ccaulfie, cluster-maint, pyaduvan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2006-0705 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-11 16:50:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 207487    
Attachments:
Description Flags
test case supplied by support front end engineer (Piyush Yaduvanshi)
none
fix to the bug none

Description Wendy Cheng 2006-09-15 05:57:15 UTC 
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 06:04:04 UTC 
Created attachment 136330 [details]
test case supplied by support front end engineer (Piyush Yaduvanshi)
Comment 2 Wendy Cheng 2006-09-15 06:15:09 UTC 
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 06:17:21 UTC 
sorry, s/unconditionally with/unconditionally return/ in above update.
Comment 4 Abhijith Das 2006-09-15 16:11:56 UTC 
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 16:26:01 UTC 
Looks good to me.
Comment 6 Abhijith Das 2006-09-15 17:44:35 UTC 
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 16:50:35 UTC 
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