[PATCH 1/2] RFC: Fix futex_wake_op fault handling (NOT FOR INCLUSION)

[Darren Hart]

As the the uaddr doesn't change after attempts to handle the fault, there is no
need to re-get the futex keys after get_user().  This patch makes successful
calls to futex_handle_fault() and get_user() start the retry from the same
point (right after the get_futex_key calls).  Also simplify the logic and
corrects missing put on the futex keys.  Finally, update the comment to more
accurate reflect the current code (we no hold the mm sem here).

Signed-off-by: Darren Hart <dvhltc@xxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
---

 kernel/futex.c |   23 ++++++++---------------
 1 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 206d4c9..c15c029 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -745,7 +745,6 @@ futex_wake_op(u32 __user *uaddr1, int fshared, u32 __user *uaddr2,
 	struct futex_q *this, *next;
 	int ret, op_ret, attempt = 0;
 
-retryfull:
 	ret = get_futex_key(uaddr1, fshared, &key1);
 	if (unlikely(ret != 0))
 		goto out;
@@ -782,25 +781,19 @@ retry:
 		}
 
 		/*
-		 * futex_atomic_op_inuser needs to both read and write
-		 * *(int __user *)uaddr2, but we can't modify it
-		 * non-atomically.  Therefore, if get_user below is not
-		 * enough, we need to handle the fault ourselves, while
-		 * still holding the mmap_sem.
+		 * We need to read and write *(int __user *)uaddr2 atomically.
+		 * Therefore, if get_user below is not enough, we need to
+		 * handle the fault ourselves.
 		 */
-		if (attempt++) {
+		if (attempt++)
 			ret = futex_handle_fault((unsigned long)uaddr2,
 						 attempt);
-			if (ret)
-				goto out_put_keys;
-			goto retry;
-		}
+		else
+			ret = get_user(dummy, uaddr2);
 
-		ret = get_user(dummy, uaddr2);
 		if (ret)
-			return ret;
-
-		goto retryfull;
+			goto out_put_keys;
+		goto retry;
 	}
 
 	head = &hb1->chain;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/