From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1415380610.23530.12.camel@perches.com> Subject: Re: [PATCH v2 3.18-rc3] kdb: Avoid printing KERN_ levels to consoles From: Joe Perches To: Daniel Thompson Cc: Jason Wessel , linux-kernel@vger.kernel.org, kgdb-bugreport@lists.sourceforge.net, Andrew Morton , Ingo Molnar , patches@linaro.org, linaro-kernel@lists.linaro.org, John Stultz , Sumit Semwal , stable@vger.kernel.org Date: Fri, 07 Nov 2014 09:16:50 -0800 In-Reply-To: <545CF847.3020409@linaro.org> References: <1415287626-25802-1-git-send-email-daniel.thompson@linaro.org> <1415361686-3797-1-git-send-email-daniel.thompson@linaro.org> <1415376272.23530.10.camel@perches.com> <545CF847.3020409@linaro.org> Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On Fri, 2014-11-07 at 16:50 +0000, Daniel Thompson wrote: > On 07/11/14 16:04, Joe Perches wrote: > > why insert KERN_INFO? > > vkdb_printf() and printk() can appear either way round in a stack > trace. Each is capable of calling the other and a flag (kdb_trap_printk) > is used to prevent mutual recursion. I see. > A complete solution would require a means to know whether vkdb_printf() > were entered directly or from printk(). A flag passed to vkdb_printf() > would achieve this. I'll take a look. That bit seems pretty simple and sensible. I don't know this code at all but would it be better if the kdb_trap_printk accesses were converted to atomic_? Might this bit in vkdb_printf: saved_trap_printk = kdb_trap_printk; kdb_trap_printk = 0; be better atomic_xchg? and the kdb_trap_printk++ bits as atomic_inc, etc...