Messages in this thread | | | Date | Tue, 13 May 2014 16:20:41 -0400 | From | Steven Rostedt <> | Subject | Re: [patch 1/3] rtmutex: Add missing deadlock check |
| |
On Tue, 13 May 2014 21:42:54 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 13 May 2014, Peter Zijlstra wrote: > > > > Now, if you and Steve get this sorted, nothing really happened except > > that Thomas got grumpy, which is entirely normal, what else would he be? > > :-) > > Who is that grumpy Thomas dude, should I know him? > > Lai, Steven, > > before you waste lots of time on the tester, I want to look at it > whether we can simplify it or even rewrite it from scratch. I glanced > at it today and I really can't remember what kind of substances were > involved when I wrote this almost a decade ago.
Thank God. /me removes the ton of trace_printk()s in the code as well as all the trace_marker.write("%s" %(line)) from the test to figure out what was going on.
> > The whole schedule_rt_mutex mechanism was mostly done to create > controlled lock stealing scenarios and deal with the BKL > oddities. > > With Lai's simplification and the demise of BKL I'm quite sure we do > not need it anymore. > > So we can just get rid of the complexity in schedule_rt_mutex() and > replace it with a simple: > > while (!td->continue) > schedule(); > > That would also make the teardown and reset of the whole thing > manageable. Right now it's easy to create a situation where unrolling > stuff gets almost impossible except by pushing the reset button. > > The state readouts can be done directly via the rtmutexes and the task > structs. > > Thoughts? >
What about having a module that creates a bunch of threads and forces all the scenarios that we want to test? Wouldn't it be easier to do than to have a userspace interface to dictate commands to the kernel?
-- Steve
| |