1 files changed, 57 insertions, 0 deletions
diff --git a/patches/futex__Clarify_comment_in_futex_requeue.patch b/patches/futex__Clarify_comment_in_futex_requeue.patch
new file mode 100644
index 000000000000..bffafb248852
--- /dev/null
+++ b/patches/futex__Clarify_comment_in_futex_requeue.patch
@@ -0,0 +1,57 @@
+Subject: futex: Clarify comment in futex_requeue()
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue Jul  6 16:36:56 2021 +0200
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+The comment about the restriction of the number of waiters to wake for the
+REQUEUE_PI case is confusing at best. Rewrite it.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+
+
+
+---
+ kernel/futex.c | 28 ++++++++++++++++++++--------
+ 1 file changed, 20 insertions(+), 8 deletions(-)
+---
+diff --git a/kernel/futex.c b/kernel/futex.c
+index 8ffeb9871476..e92c871aa133 100644
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -1960,15 +1960,27 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags,
+ 		 */
+ 		if (refill_pi_state_cache())
+ 			return -ENOMEM;
++
+ 		/*
+-		 * requeue_pi must wake as many tasks as it can, up to nr_wake
+-		 * + nr_requeue, since it acquires the rt_mutex prior to
+-		 * returning to userspace, so as to not leave the rt_mutex with
+-		 * waiters and no owner.  However, second and third wake-ups
+-		 * cannot be predicted as they involve race conditions with the
+-		 * first wake and a fault while looking up the pi_state.  Both
+-		 * pthread_cond_signal() and pthread_cond_broadcast() should
+-		 * use nr_wake=1.
++		 * futex_requeue() allows the caller to define the number
++		 * of waiters to wake up via the @nr_wake argument. With
++		 * REQUEUE_PI waking up more than one waiter is creating
++		 * more problems than it solves. Waking up a waiter makes
++		 * only sense if the PI futex @uaddr2 is uncontended as
++		 * this allows the requeue code to acquire the futex
++		 * @uaddr2 before waking the waiter. The waiter can then
++		 * return to user space without further action. A secondary
++		 * wakeup would just make the futex_wait_requeue_pi()
++		 * handling more complex because that code would have to
++		 * look up pi_state and do more or less all the handling
++		 * which the requeue code has to do for the to be requeued
++		 * waiters. So restrict the number of waiters to wake to
++		 * one and only wake it up when the PI futex is
++		 * uncontended. Otherwise requeue it and let the unlock of
++		 * the PI futex handle the wakeup.
++		 *
++		 * All REQUEUE_PI users, e.g. pthread_cond_signal() and
++		 * pthread_cond_broadcast() must use nr_wake=1.
+ 		 */
+ 		if (nr_wake != 1)
+ 			return -EINVAL;