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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 May 2014 15:00:09 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Darren Hart <darren@...art.com>,
	Davidlohr Bueso <davidlohr@...com>,
	Ingo Molnar <mingo@...nel.org>,
	Clark Williams <williams@...hat.com>,
	Roland McGrath <roland@...k.frob.com>,
	Carlos ODonell <carlos@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [patch 1/3] rtmutex: Add missing deadlock check

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/