Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel
BUG at kernel/locking/rtmutex.c:997!
[Posted March 4, 2015 by corbet]
| From: |
| Steven Rostedt <rostedt-AT-goodmis.org> |
| To: |
| Sebastian Andrzej Siewior <bigeasy-AT-linutronix.de> |
| Subject: |
| Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997! |
| Date: |
| Thu, 26 Feb 2015 09:06:10 -0500 |
| Message-ID: |
| <20150226090610.7eb0ac61@gandalf.local.home> |
| Cc: |
| Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke-AT-hp.com>, Thavatchai Makphaibulchoke <tmac-AT-hp.com>, linux-kernel-AT-vger.kernel.org, mingo-AT-redhat.com, tglx-AT-linutronix.de, linux-rt-users-AT-vger.kernel.org |
| Archive‑link: | |
Article |
On Thu, 26 Feb 2015 14:56:30 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> I am not sure if we want keep doing that. The only reason why we grab
> the lock in the first place was to check if there is a timer pending
> and we run on the isolated CPU. It should not matter for the other CPUs,
> right?
> So instead going further that road, what about storing base->next_timer
> someplace so it can be obtained via atomic_read() for the isolated CPUs?
>
If we can pull that off and remove all rtmutex trylocks from hardirq
context, I would much rather do that.
This hocus pocus coding is just going to lead us down the path of the
black arts. I already have a black cat, so I'm good to go.
-- Steve
