mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Clark Williams <williams@redhat.com>
Subject: Re: safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc)
Date: Tue, 10 Jun 2014 10:53:32 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1406101051210.3830@nanos> (raw)
In-Reply-To: <20140609154114.20585056@gandalf.local.home>

On Mon, 9 Jun 2014, Steven Rostedt wrote:
> On Mon, 9 Jun 2014 11:51:09 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Because spinlocks are atomic, this is all fine, but if you have a
> mutex, then this is where you can have issues. I think rtmutex has an
> issue with it too. Specifically in the slow_unlock case:
> 
> 	if (!rt_mutex_has_waiters(lock)) {
> 		lock->owner = NULL;
> 		raw_spin_unlock(&lock->wait_lock);
> 		return;
> 	}

Indeed. If the fast path is enabled we have that issue. Fortunately
there is a halfways reasonable solution for this.

Thanks,

	tglx
--------------------------->
Subject: rtmutex: Plug slow unlock race
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 10 Jun 2014 09:27:00 +0200

When the rtmutex fast path is enabled the slow unlock function can
create the following situation:

spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
	    			rt_mutex_lock(foo->m); <-- fast path
				free = atomic_dec_and_test(foo->refcnt);
				rt_mutex_unlock(foo->m); <-- fast path
				if (free)
				   kfree(foo);

spin_unlock(foo->m->wait_lock); <--- Use after free.

Plug the race by changing the slow unlock to the following scheme:

     while (!rt_mutex_has_waiters(m)) {
     	    /* Clear the waiters bit in m->owner */
	    clear_rt_mutex_waiters(m);
      	    owner = rt_mutex_owner(m);
      	    spin_unlock(m->wait_lock);
      	    if (cmpxchg(m->owner, owner, 0) == owner)
      	       return;
      	    spin_lock(m->wait_lock);
     }

So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:

 unlock(wait_lock);
					lock(wait_lock);
 cmpxchg(p, owner, 0) == owner
 	    	   			mark_rt_mutex_waiters(lock);
	 				acquire(lock);

Or:

 unlock(wait_lock);
					lock(wait_lock);
	 				mark_rt_mutex_waiters(lock);
 cmpxchg(p, owner, 0) != owner
					enqueue_waiter();
					unlock(wait_lock);
 lock(wait_lock);
 wake waiter();
 unlock(wait_lock);
					lock(wait_lock);
					acquire(lock);

If the fast path is disabled, then the simple

   m->owner = NULL;
   unlock(m->wait_lock);

is sufficient as all access to m->owner is serialized via
m->wait_lock;


Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/locking/rtmutex.c |   94 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 90 insertions(+), 4 deletions(-)

Index: tip/kernel/locking/rtmutex.c
===================================================================
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -83,6 +83,48 @@ static inline void mark_rt_mutex_waiters
 		owner = *p;
 	} while (cmpxchg(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner);
 }
+
+/*
+ * Safe fastpath aware unlock:
+ * 1) Clear the waiters bit
+ * 2) Drop lock->wait_lock
+ * 3) Try to unlock the lock with cmpxchg
+ */
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+	__releases(lock->wait_lock)
+{
+	unsigned long owner, *p = (unsigned long *) &lock->owner;
+
+	owner = (unsigned long) rt_mutex_owner(lock);
+	clear_rt_mutex_waiters(lock);
+	raw_spin_unlock(&lock->wait_lock);
+	/*
+	 * If a new waiter comes in between the unlock and the cmpxchg
+	 * we have two situations:
+	 *
+	 * unlock(wait_lock);
+	 *					lock(wait_lock);
+	 * cmpxchg(p, owner, 0) == owner
+	 *					mark_rt_mutex_waiters(lock);
+	 *					acquire(lock);
+	 * or:
+	 *
+	 * unlock(wait_lock);
+	 *					lock(wait_lock);
+	 *					mark_rt_mutex_waiters(lock);
+	 *
+	 * cmpxchg(p, owner, 0) != owner
+	 *					enqueue_waiter();
+	 *					unlock(wait_lock);
+	 * lock(wait_lock);
+	 * wake waiter();
+	 * unlock(wait_lock);
+	 *					lock(wait_lock);
+	 *					acquire(lock);
+	 */
+	return rt_mutex_cmpxchg(p, owner, 0);
+}
+
 #else
 # define rt_mutex_cmpxchg(l,c,n)	(0)
 static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
@@ -90,6 +132,17 @@ static inline void mark_rt_mutex_waiters
 	lock->owner = (struct task_struct *)
 			((unsigned long)lock->owner | RT_MUTEX_HAS_WAITERS);
 }
+
+/*
+ * Simple slow path only version: owner is protected by wait_lock
+ */
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+	__releases(lock->wait_lock)
+{
+	lock->owner = NULL;
+	raw_spin_unlock(&lock->wait_lock);
+	return true;
+}
 #endif
 
 static inline int
@@ -928,10 +981,43 @@ rt_mutex_slowunlock(struct rt_mutex *loc
 
 	rt_mutex_deadlock_account_unlock(current);
 
-	if (!rt_mutex_has_waiters(lock)) {
-		lock->owner = NULL;
-		raw_spin_unlock(&lock->wait_lock);
-		return;
+	/*
+	 * We must be careful here if the fast path is enabled. If we
+	 * have no waiters queued we cannot set owner to NULL here
+	 * because of:
+	 *
+	 * foo->lock->owner = NULL;
+	 *			rtmutex_lock(foo->lock);   <- fast path
+	 *			free = atomic_dec_and_test(foo->refcnt);
+	 *			rtmutex_unlock(foo->lock); <- fast path
+	 *			if (free)
+	 *				kfree(foo);
+	 * raw_spin_unlock(foo->lock->wait_lock);
+	 *
+	 * So for the fastpath enabled kernel:
+	 *
+	 * Nothing can set the waiters bit as long as we hold
+	 * lock->wait_lock. So we do the following sequence:
+	 *
+	 *	owner = rt_mutex_owner(lock);
+	 *	clear_rt_mutex_waiters(lock);
+	 *	raw_spin_unlock(&lock->wait_lock);
+	 *	if (cmpxchg(&lock->owner, owner, 0) == owner)
+	 *		return;
+	 *	goto retry;
+	 *
+	 * The fastpath disabled variant is simple as all access to
+	 * lock->owner is serialized by lock->wait_lock:
+	 *
+	 *	lock->owner = NULL;
+	 *	raw_spin_unlock(&lock->wait_lock);
+	 */
+	while (!rt_mutex_has_waiters(lock)) {
+		/* Drops lock->wait_lock ! */
+		if (unlock_rt_mutex_safe(lock) == true)
+			return;
+		/* Relock the rtmutex and try again */
+		raw_spin_lock(&lock->wait_lock);
 	}
 
 	wakeup_next_waiter(lock);

  reply	other threads:[~2014-06-10  8:53 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 17:02 [BUG] signal: sighand unprotected when accessed by /proc Steven Rostedt
2014-06-03 17:26 ` Oleg Nesterov
2014-06-03 18:03   ` Linus Torvalds
2014-06-03 20:01     ` Oleg Nesterov
2014-06-03 20:03       ` Oleg Nesterov
2014-06-06 20:33       ` Paul E. McKenney
2014-06-08 13:07         ` safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc) Oleg Nesterov
2014-06-09 16:26           ` Paul E. McKenney
2014-06-09 18:15             ` Oleg Nesterov
2014-06-09 18:29               ` Steven Rostedt
2014-06-09 18:51                 ` Linus Torvalds
2014-06-09 19:41                   ` Steven Rostedt
2014-06-10  8:53                     ` Thomas Gleixner [this message]
2014-06-10 16:57                       ` Oleg Nesterov
2014-06-10 18:08                         ` Thomas Gleixner
2014-06-10 18:13                           ` Steven Rostedt
2014-06-10 20:05                             ` Thomas Gleixner
2014-06-10 20:13                               ` Thomas Gleixner
2014-06-11 15:52                                 ` Paul E. McKenney
2014-06-11 17:07                                   ` Oleg Nesterov
2014-06-11 17:17                                     ` Oleg Nesterov
2014-06-11 17:29                                       ` Paul E. McKenney
2014-06-11 17:59                                         ` Oleg Nesterov
2014-06-11 19:56                                           ` Paul E. McKenney
2014-06-12 17:28                                             ` Oleg Nesterov
2014-06-12 20:35                                               ` Paul E. McKenney
2014-06-12 21:40                                                 ` Thomas Gleixner
2014-06-12 22:27                                                   ` Paul E. McKenney
2014-06-12 23:19                                                     ` Paul E. McKenney
2014-06-13 15:08                                                       ` Oleg Nesterov
2014-06-15  5:40                                                         ` Paul E. McKenney
2014-06-17 18:57                                                           ` Paul E. McKenney
2014-06-18 16:43                                                             ` Oleg Nesterov
2014-06-18 16:53                                                               ` Steven Rostedt
2014-06-21 19:54                                                                 ` Thomas Gleixner
2014-06-18 17:00                                                               ` Paul E. McKenney
2014-06-13 14:55                                                   ` Oleg Nesterov
2014-06-13 16:10                                                     ` Thomas Gleixner
2014-06-13 16:19                                                       ` Oleg Nesterov
2014-06-13 14:52                                                 ` Oleg Nesterov
2014-06-11 17:27                                     ` Paul E. McKenney
2014-06-10 17:07                       ` Oleg Nesterov
2014-06-10 17:51                         ` Thomas Gleixner
2014-06-10 12:56                   ` Paul E. McKenney
2014-06-10 14:48                     ` Peter Zijlstra
2014-06-10 15:18                       ` Paul E. McKenney
2014-06-10 15:35                     ` Linus Torvalds
2014-06-10 16:15                       ` Paul E. McKenney
2014-06-09 19:04                 ` Oleg Nesterov
2014-06-10  8:37             ` Peter Zijlstra
2014-06-10 12:52               ` Paul E. McKenney
2014-06-10 13:01                 ` Peter Zijlstra
2014-06-10 14:36                   ` Paul E. McKenney
2014-06-10 15:20                     ` Paul E. McKenney
2014-06-03 20:05     ` [BUG] signal: sighand unprotected when accessed by /proc Steven Rostedt
2014-06-03 20:09       ` Oleg Nesterov
2014-06-03 20:15         ` Steven Rostedt
2014-06-03 20:25         ` Steven Rostedt
2014-06-03 21:12           ` Thomas Gleixner
2014-06-03 18:05   ` Steven Rostedt
2014-06-03 19:25     ` Oleg Nesterov
2014-06-04  1:16       ` Steven Rostedt
2014-06-04 16:31         ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1406101051210.3830@nanos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=williams@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®