Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755119AbaD1KYh (ORCPT ); Mon, 28 Apr 2014 06:24:37 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:35182 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755049AbaD1KYe (ORCPT ); Mon, 28 Apr 2014 06:24:34 -0400 Message-ID: <535E2C5A.9090702@linaro.org> Date: Mon, 28 Apr 2014 11:24:26 +0100 From: Daniel Thompson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Steven Rostedt CC: kgdb-bugreport@lists.sourceforge.net, Jason Wessel , patches@linaro.org, linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Jiri Slaby , Frederic Weisbecker , Ingo Molnar , John Stultz , Anton Vorontsov , Colin Cross , kernel-team@android.com Subject: Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid recursive locking in kdb References: <1396453440-16445-1-git-send-email-daniel.thompson@linaro.org> <1398443370-12668-1-git-send-email-daniel.thompson@linaro.org> <1398443370-12668-2-git-send-email-daniel.thompson@linaro.org> <20140425124530.52fd696c@gandalf.local.home> In-Reply-To: <20140425124530.52fd696c@gandalf.local.home> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/04/14 17:45, Steven Rostedt wrote: > On Fri, 25 Apr 2014 17:29:22 +0100 > Daniel Thompson 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/