linux-kernel - RE: [PATCH 1/7] Add die_spin_lock

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: <063D6719AE5E284EB5DD2968C1650D6D1CAE9BD3@AcuExch.aculab.com>
Date:	Tue, 24 Feb 2015 09:56:14 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Ingo Molnar' <mingo@...nel.org>, Anton Blanchard <anton@...ba.org>
CC:	Don Zickus <dzickus@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	Russell King <linux@....linux.org.uk>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"sam.bobroff@....ibm.com" <sam.bobroff@....ibm.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: RE: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}

From: Ingo Molnar
...
> So why not trylock and time out here after a few seconds,
> instead of indefinitely supressing some potentially vital
> output due to some other CPU crashing/locking with the lock
> held?

I've used that for status requests that usually lock a table
to get a consistent view.
If trylock times out assume that the data is actually stable
and access it anyway. Remember the pid doing the access and
next time it tries to acquire the same lock do a trylock with
no timeout.
That way if (when) there is a locking fubar (or a driver oops
with a lock held) at least some of the relevant status commands
will work.

	David