Bug 206590 - fcntl(F_UNLCK) return code
Summary: fcntl(F_UNLCK) return code
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: dlm
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Abhijith Das
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 207487
TreeView+ depends on / blocked
 
Reported: 2006-09-15 05:57 UTC by Wendy Cheng
Modified: 2009-04-16 19:55 UTC (History)
3 users (show)

Fixed In Version: RHBA-2006-0705
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-11 16:50:35 UTC
Embargoed:


Attachments (Terms of Use)
test case supplied by support front end engineer (Piyush Yaduvanshi) (621 bytes, text/plain)
2006-09-15 06:04 UTC, Wendy Cheng
no flags Details
fix to the bug (593 bytes, patch)
2006-09-15 16:11 UTC, Abhijith Das
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0705 0 normal SHIPPED_LIVE GFS-kernel bug fix update 2006-10-11 16:49:30 UTC

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



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