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]

Message-ID: <alpine.DEB.2.02.1405132117110.6261@ionos.tec.linutronix.de>
Date:	Tue, 13 May 2014 21:42:54 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	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>,
	Steven Rostedt <rostedt@...dmis.org>,
	Clark Williams <williams@...hat.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.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, 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.

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?

Thanks,

	tglx
--
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/