Messages in this thread | | | Date | Thu, 26 Feb 2015 09:06:10 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997! |
| |
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
| |