All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thavatchai Makphaibulchoke <tmac@hp.com>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, linux-rt-users@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH v2 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!
Date: Tue, 07 Apr 2015 07:09:43 +0200	[thread overview]
Message-ID: <1428383383.3152.5.camel@gmail.com> (raw)
In-Reply-To: <20150406215959.4e8ad37b@grimm.local.home>

On Mon, 2015-04-06 at 21:59 -0400, Steven Rostedt wrote:
> 
> We really should have a rt_spin_trylock_in_irq() and not have the
> below if conditional.
> 
> The paths that will be executed in hard irq context are static. They
> should be labeled as such.

I did it as an explicitly labeled special purpose (naughty) pair.

---
 include/linux/spinlock_rt.h |    2 ++
 kernel/locking/rtmutex.c    |   31 ++++++++++++++++++++++++++++++-
 2 files changed, 32 insertions(+), 1 deletion(-)

--- a/include/linux/spinlock_rt.h
+++ b/include/linux/spinlock_rt.h
@@ -27,6 +27,8 @@ extern void __lockfunc rt_spin_unlock_wa
 extern int __lockfunc rt_spin_trylock_irqsave(spinlock_t *lock, unsigned long *flags);
 extern int __lockfunc rt_spin_trylock_bh(spinlock_t *lock);
 extern int __lockfunc rt_spin_trylock(spinlock_t *lock);
+extern int __lockfunc rt_spin_trylock_in_irq(spinlock_t *lock);
+extern void __lockfunc rt_spin_trylock_in_irq_unlock(spinlock_t *lock);
 extern int atomic_dec_and_spin_lock(atomic_t *atomic, spinlock_t *lock);
 
 /*
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -87,7 +87,7 @@ static int rt_mutex_real_waiter(struct r
  * supports cmpxchg and if there's no debugging state to be set up
  */
 #if defined(__HAVE_ARCH_CMPXCHG) && !defined(CONFIG_DEBUG_RT_MUTEXES)
-# define rt_mutex_cmpxchg(l,c,n)       (cmpxchg(&l->owner, c, n) == c)
+# define rt_mutex_cmpxchg(l,c,n)       (cmpxchg(&(l)->owner, (c), (n)) == (c))
 static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
 {
        unsigned long owner, *p = (unsigned long *) &lock->owner;
@@ -1208,6 +1208,35 @@ int __lockfunc rt_spin_trylock_irqsave(s
 }
 EXPORT_SYMBOL(rt_spin_trylock_irqsave);
 
+/*
+ * Special purpose for locks taken in interrupt context: Take and hold
+ * ->wait_lock lest PI catching us with our fingers in the cookie jar.
+ * Do NOT abuse.
+ */
+int __lockfunc rt_spin_trylock_in_irq(spinlock_t *lock)
+{
+       struct task_struct *owner;
+       if (!raw_spin_trylock(&lock->lock.wait_lock))
+               return 0;
+       owner = idle_task(raw_smp_processor_id());
+       if (!(rt_mutex_cmpxchg(&lock->lock, NULL, owner))) {
+               raw_spin_unlock(&lock->lock.wait_lock);
+               return 0;
+       }
+       spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
+       return 1;
+}
+
+/* ONLY for use with rt_spin_trylock_in_irq(), do NOT abuse. */
+void __lockfunc rt_spin_trylock_in_irq_unlock(spinlock_t *lock)
+{
+       struct task_struct *owner = idle_task(raw_smp_processor_id());
+       /* NOTE: we always pass in '1' for nested, for simplicity */
+       spin_release(&lock->dep_map, 1, _RET_IP_);
+       BUG_ON(!(rt_mutex_cmpxchg(&lock->lock, owner, NULL)));
+       raw_spin_unlock(&lock->lock.wait_lock);
+}
+
 int atomic_dec_and_spin_lock(atomic_t *atomic, spinlock_t *lock)
 {
        /* Subtract 1 from counter unless that drops it to 0 (ie. it was 1) */

  reply	other threads:[~2015-04-07  5:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20  1:31 [PATCH 3.14.25-rt22 0/2] rtmutex Real-Time Linux: fix kernel BUG at kernel/locking/rtmutex.c:997! and some optimization Thavatchai Makphaibulchoke
2015-02-20  1:31 ` [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997! Thavatchai Makphaibulchoke
2015-02-20  4:53   ` Steven Rostedt
2015-02-20 18:54     ` Thavatchai Makphaibulchoke
2015-02-21  1:49       ` Steven Rostedt
2015-02-23 18:37   ` Steven Rostedt
2015-02-24  0:16     ` Thavatchai Makphaibulchoke
2015-02-24  0:57       ` Steven Rostedt
2015-02-26 13:56         ` Sebastian Andrzej Siewior
2015-02-26 14:06           ` Steven Rostedt
2015-03-06 12:19             ` Sebastian Andrzej Siewior
2015-03-09 16:36               ` Steven Rostedt
2015-03-09 16:49                 ` Sebastian Andrzej Siewior
2015-02-20  1:31 ` [PATCH 3.14.25-rt22 2/2] kernel/locking/rtmutex.c: some code optimization Thavatchai Makphaibulchoke
2015-04-07  1:26 ` [PATCH v2 0/2] rtmutex Real-Time Linux: fix BUG at kernel/locking/rtmutex.c:997! Thavatchai Makphaibulchoke
2015-04-07  1:26   ` [PATCH v2 1/2] rtmutex Real-Time Linux: Fixing kernel " Thavatchai Makphaibulchoke
2015-04-07  1:59     ` Steven Rostedt
2015-04-07  5:09       ` Mike Galbraith [this message]
2015-04-07 10:29         ` Peter Zijlstra
2015-04-07 10:49           ` Mike Galbraith
2015-04-07 10:56             ` Peter Zijlstra
2015-04-07 11:01               ` Mike Galbraith
2015-04-08  0:55       ` Thavatchai Makphaibulchoke
2015-04-08  8:50         ` Thomas Gleixner
2015-04-09 22:56           ` Thavatchai Makphaibulchoke
2015-04-07 11:23     ` Thomas Gleixner
2015-04-07 11:47       ` Mike Galbraith
2015-04-07 12:04         ` Peter Zijlstra
2015-04-07 12:07           ` Peter Zijlstra
2015-04-07 12:41           ` Steven Rostedt
2015-04-07 12:54             ` Peter Zijlstra
2015-04-07 13:58               ` Steven Rostedt
2015-04-07 18:12           ` Jason Low
2015-04-07 19:17             ` Thomas Gleixner
2015-04-07 19:57               ` Jason Low
2015-04-07 21:38                 ` Thomas Gleixner
2015-04-07  1:26   ` [PATCH v2 2/2] kernel/locking/rtmutex.c: some code optimization Thavatchai Makphaibulchoke

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=1428383383.3152.5.camel@gmail.com \
    --to=umgwanakikbuti@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tmac@hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.