I am still concerned that an approach that uses the lm_get/put_owner methods is unworkable because that API is used in several unrelated situations. For example, a successful LOCK operation does a get_owner and put_owner on the lockowner; the put_owner is called from free_blocked_lock. A successful UNLOCK operation does two put_owner calls; once from posix_lock_inode and once from locks_free_lock. Thus I believe it would be difficult to change fs/locks to count locks accurately via the lm_get/put_owner API. Even if we could get the lock counting right today, the API so far is confusing enough to be vulnerable to breakage by subsequent changes in this area. Therefore I'm leaning towards the so_count-based approach as shown in this version of the patch series. --- Chuck Lever (4): NFSD: Fix possible sleep during nfsd4_release_lockowner() NFSD: Modernize nfsd4_release_lockowner() NFSD: Add documenting comment for nfsd4_release_lockowner() NFSD: nfsd_file_put() can sleep fs/nfsd/filecache.c | 2 ++ fs/nfsd/nfs4state.c | 63 ++++++++++++++++++++++----------------------- 2 files changed, 33 insertions(+), 32 deletions(-) -- Chuck Lever