On Fri, 25 Apr 2014 17:29:22 +0100 Daniel Thompson <[email protected]> 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? -- Steve ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
