linux-kernel - Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq

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: <535F69F8.8040707@linaro.org>
Date:	Tue, 29 Apr 2014 09:59:36 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Colin Cross <ccross@...roid.com>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	kgdb-bugreport@...ts.sourceforge.net,
	Jason Wessel <jason.wessel@...driver.com>,
	"patches@...aro.org" <patches@...aro.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	John Stultz <john.stultz@...aro.org>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid
 recursive locking in kdb

On 28/04/14 18:44, Colin Cross wrote:
>>> Is that case documented somewhere in the code comments?
>>
>> Perhaps not near enough to the _nolock but the primary bit of comment is
>> here (and in same file as kdb_sr).
>> --- cut here ---
>>  * kdb_main_loop - After initial setup and assignment of the
>>  *      controlling cpu, all cpus are in this loop.  One cpu is in
>>  *      control and will issue the kdb prompt, the others will spin
>>  *      until 'go' or cpu switch.
>> --- cut here ---
>>
>> The mechanism kgdb uses to quiesce other CPUs means other CPUs cannot be
>> in irqsave critical sections.
>>
>>
> 
> One of the advantages of FIQ debugger is that it can be triggered from
> an FIQ (NMI for those in x86 land), and Jason and I have discussed
> using FIQs for kgdb to allow interrupting cpus stuck in critical
> sections.  If that gets implemented the above assumption will no
> longer be correct.

Reviewing this I realized I missed one of the most critical points in
the above.

Today kdb, even if triggered by FIQ/NMI, would still be likely to wedge
waiting for the IPI interrupts to be delivered to other processors.

Did you and Jason discuss getting the active CPU to quiesce the other
processors using FIQ/NMI, or to allow the active CPU to timeout while
waiting for them the stop?


Daniel.
--
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/