linux-kernel - [GIT PULL] rtmutex: Fix comment about why new_owner can be NULL in wake_futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Jan 2011 23:17:49 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Darren Hart <darren@...art.com>,
	Lai Jiangshan <eag0628@...il.com>
Subject: [GIT PULL] rtmutex: Fix comment about why new_owner can be NULL in
 wake_futex_pi()


Ingo,

While porting Lai Jiangshan's rt-pi patch to the -rt kernel, I found
that the comment about why rt_mutex_next_owner() can return NULL is
incorrect. This caused Lai to remove the following if condition, which
caused a bit of headache in debugging why his patch was causing a crash.

Please pull the latest tip/futex tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/futex


Steven Rostedt (1):
      rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()

----
 kernel/futex.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)
---------------------------
commit 03cb8f564241019619d52b8716a8194b4220871c
Author: Steven Rostedt <srostedt@...hat.com>
Date:   Thu Jan 6 15:08:29 2011 -0500

    rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()
    
    The comment about why rt_mutex_next_owner() can return NULL in
    wake_futex_pi() is not the normal case.
    
    Tracing the cause of why this occurs is more likely that waiter
    simply timedout. But because it originally caused contention with
    the futex, the owner will go into the kernel when it unlocks
    the lock. Then it will hit this code path and
    rt_mutex_next_owner() will return NULL.
    
    Cc: Thomas Gleixner <tglx@...utronix.de>
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/kernel/futex.c b/kernel/futex.c
index 3019b92..5696d38 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -791,10 +791,9 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this)
 	new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
 
 	/*
-	 * This happens when we have stolen the lock and the original
-	 * pending owner did not enqueue itself back on the rt_mutex.
-	 * Thats not a tragedy. We know that way, that a lock waiter
-	 * is on the fly. We make the futex_q waiter the pending owner.
+	 * It is possible that the next waiter (the one that brought
+	 * this owner to the kernel) timed out and is no longer
+	 * waiting on the lock.
 	 */
 	if (!new_owner)
 		new_owner = this->task;


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