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:
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 though. 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: 1.12.8.3; previous revision: 1.12.8.2 done
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