locks: don't call ->copy_lock methods on return of conflicting locks

The file_lock structure is used both as a heavy-weight representation of
an active lock, with pointers to reference-counted structures, etc., and
as a simple container for parameters that describe a file lock.

The conflicting lock returned from __posix_lock_file is an example of
the latter; so don't call the filesystem or lock manager callbacks when
copying to it.  This also saves the need for an unnecessary
locks_init_lock in the nfsv4 server.

Thanks to Trond for pointing out the error.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>

1 files changed, 0 insertions, 3 deletions

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 55dfdd71f1b0..8799b8708188 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -2712,9 +2712,6 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
         * Note: locks.c uses the BKL to protect the inode's lock list.
         */
 
-        /* XXX?: Just to divert the locks_release_private at the start of
-         * locks_copy_lock: */
-        locks_init_lock(&conflock);
         err = vfs_lock_file(filp, cmd, &file_lock, &conflock);
         switch (-err) {
         case 0: /* success! */