From: Jeff Layton Subject: [PATCH 1/5] locks: don't call locks_release_private from locks_copy_lock Date: Tue, 12 Aug 2014 10:48:09 -0400 Message-ID: <1407854893-2698-2-git-send-email-jlayton@primarydata.com> References: <1407854893-2698-1-git-send-email-jlayton@primarydata.com> Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org To: linux-fsdevel@vger.kernel.org Return-path: In-Reply-To: <1407854893-2698-1-git-send-email-jlayton@primarydata.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org All callers of locks_copy_lock pass in a brand new file_lock struct, so there's no need to calls locks_release_private on it. Replace that with a warning that fires in the event that we receive a target lock that doesn't look like it's properly initialized. Signed-off-by: Jeff Layton --- fs/locks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 356667a434c1..2c2d4f5022a7 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -285,7 +285,8 @@ EXPORT_SYMBOL(__locks_copy_lock); void locks_copy_lock(struct file_lock *new, struct file_lock *fl) { - locks_release_private(new); + /* "new" must be a freshly-initialized lock */ + WARN_ON_ONCE(new->fl_ops); __locks_copy_lock(new, fl); new->fl_file = fl->fl_file; -- 1.9.3