From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759875AbcLBKq1 (ORCPT ); Fri, 2 Dec 2016 05:46:27 -0500 Received: from terminus.zytor.com ([198.137.202.10]:42144 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759779AbcLBKqY (ORCPT ); Fri, 2 Dec 2016 05:46:24 -0500 Date: Fri, 2 Dec 2016 02:45:46 -0800 From: tip-bot for Thomas Gleixner Message-ID: Cc: mark.rutland@arm.com, rostedt@goodmis.org, linux-kernel@vger.kernel.org, mingo@kernel.org, ddaney@caviumnetworks.com, hpa@zytor.com, stable@vger.kernel.org, torvalds@linux-foundation.org, peterz@infradead.org, bigeasy@linutronix.de, will.deacon@arm.com, tglx@linutronix.de Reply-To: hpa@zytor.com, mingo@kernel.org, linux-kernel@vger.kernel.org, ddaney@caviumnetworks.com, rostedt@goodmis.org, mark.rutland@arm.com, tglx@linutronix.de, will.deacon@arm.com, peterz@infradead.org, bigeasy@linutronix.de, torvalds@linux-foundation.org, stable@vger.kernel.org In-Reply-To: <20161130210030.431379999@linutronix.de> References: <20161130210030.431379999@linutronix.de> To: linux-tip-commits@vger.kernel.org Subject: [tip:locking/core] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() Git-Commit-ID: 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d Gitweb: http://git.kernel.org/tip/1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d Author: Thomas Gleixner AuthorDate: Wed, 30 Nov 2016 21:04:42 +0000 Committer: Ingo Molnar CommitDate: Fri, 2 Dec 2016 11:13:26 +0100 locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might race against the cmpxchg_release() in unlock_rt_mutex_safe(). Will: "It's a minor thing which will most likely not matter in practice" Careful search did not unearth an actual problem in todays code, but it's better to be safe than surprised. Suggested-by: Will Deacon Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: David Daney Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Steven Rostedt Cc: Link: http://lkml.kernel.org/r/20161130210030.431379999@linutronix.de Signed-off-by: Ingo Molnar --- kernel/locking/rtmutex_common.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h index 4f5f83c..e317e1c 100644 --- a/kernel/locking/rtmutex_common.h +++ b/kernel/locking/rtmutex_common.h @@ -75,8 +75,9 @@ task_top_pi_waiter(struct task_struct *p) static inline struct task_struct *rt_mutex_owner(struct rt_mutex *lock) { - return (struct task_struct *) - ((unsigned long)lock->owner & ~RT_MUTEX_OWNER_MASKALL); + unsigned long owner = (unsigned long) READ_ONCE(lock->owner); + + return (struct task_struct *) (owner & ~RT_MUTEX_OWNER_MASKALL); } /*