Re: [patch 1/3] rtmutex: Add missing deadlock check

[Paul E. McKenney]

On Tue, May 13, 2014 at 11:27:16PM +0200, Thomas Gleixner wrote:
> On Tue, 13 May 2014, Paul E. McKenney wrote:
> > On Tue, May 13, 2014 at 04:20:41PM -0400, Steven Rostedt wrote:
> > > 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?
> > 
> > I second this approach!  The kernel environment makes it -much- easier
> > to force races and other conditions, which turns into much simpler and
> > more effective tests.
> 
> The point of the rtmutex tester was NOT to force races and stuff, it
> was intended to be a formal test for certain static scenarios:
> 
>    - verify boosting / debosting
>    - verify set_scheduler interaction
>    - verify deadlock detection 
> 
> The latter was incomplete and therefor missed the futex wreckage :(
> 
> Having a formal checker makes a lot of sense.
> 
> Plastering the code with a gazillion of trace_printks, waiting several
> hours for each iteration and staring into several GB of traces just to
> figure out, that it is an algorithmic issue, is utter waste of time
> and nerves. And that stuff is definitely complex enough to justify a
> static checker.
> 
> Back then when I wrote it, it unearthed quite some logic bugs. And I
> needed the schedule_rt_mutex() hack to verify the BKL interaction and
> the lock steal machinery, which made it impossible to be a module. It
> could have been done, but that'd have been even more ugly hackery.
> 
> So I made it a user space interface to add/modify test cases without
> recompiling the kernel.  But now with BKL and the lock steal muck
> gone, we simply might kill it.
> 
> Now that allows a module, but then I'm still not sure whether formal
> verification rules are fun to code in C. There are certainly better
> ways than the *.tst rules I defined back then. But yes, we could add a
> similar cryptic thing with static arrays of OP/Data pairs in C.

Good points -- I was indeed thinking about stress testing instead of
algorithmic testing.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/