From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Carpenter <dan.carpenter@oracle.com>
Subject: [patch] fs/binfmts: double unlock in search_binary_handler()
Date: Thu, 1 Aug 2013 18:47:05 +0300
Message-ID: <20130801154705.GC5198@elgon.mountain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	kernel-janitors@vger.kernel.org
To: Zach Levis <zml@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Return-path: <kernel-janitors-owner@vger.kernel.org>
Content-Disposition: inline
Sender: kernel-janitors-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

The recent -mm patch 3046d15088 "fs/binfmts: better handling of binfmt
loops" introduced a new "continue" to the loop.  The problem is that we
are supposed to be holding the lock at the start so we need to take it
again.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker stuff.  Untested.

diff --git a/fs/exec.c b/fs/exec.c
index f8b7ed1..e2785fc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1426,6 +1426,7 @@ int search_binary_handler(struct linux_binprm *bprm)
 				copy_strings(bprm->argc_orig, *((struct user_arg_ptr *) bprm->argv_orig), bprm);
 				bprm->argc = bprm->argc_orig;
 				retval = -ENOEXEC;
+				read_lock(&binfmt_lock);
 				continue;
 			}