On 25/04/14 17:45, Steven Rostedt wrote:
On Fri, 25 Apr 2014 17:29:22 +0100 Daniel Thompson daniel.thompson@linaro.org wrote:
If kdb is triggered using SysRq-g then any use of the sr command results in the SysRq key table lock being recursively acquired, killing the debug session. That patch resolves the problem by introducing a _nolock alternative for __handle_sysrq.
Strictly speaking this approach risks racing on the key table when kdb is triggered by something other than SysRq-g however in that case any other CPU involved should release the spin lock before kgdb parks the slave CPUs.
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.