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);
next prev parent 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®