Red Hat Bugzilla – Bug 206590
fcntl(F_UNLCK) return code
Last modified: 2009-04-16 15:55:16 EDT
Description of problem:
"man 2 fcntl" says:
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)
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):
Steps to Reproduce:
Created attachment 136330 [details]
test case supplied by support front end engineer (Piyush Yaduvanshi)
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
If you want me to hack the patch, let me know.
sorry, s/unconditionally with/unconditionally return/ in above update.
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.
Looks good to me.
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: 22.214.171.124; previous revision: 126.96.36.199
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.