Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754909AbbHLMbs (ORCPT ); Wed, 12 Aug 2015 08:31:48 -0400 Received: from mail-qg0-f45.google.com ([209.85.192.45]:34968 "EHLO mail-qg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754869AbbHLMbp (ORCPT ); Wed, 12 Aug 2015 08:31:45 -0400 Message-ID: <55CB3CAC.6000003@hurleysoftware.com> Date: Wed, 12 Aug 2015 08:31:40 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Greg Kroah-Hartman CC: Pan Xinhui , "linux-kernel@vger.kernel.org" , Andrew Morton , pmladek@suse.cz, rostedt@goodmis.org, Tejun Heo , Joe Perches , hch@lst.de, viro@zeniv.linux.org.uk, Vasily Averin Subject: Re: [PATCH] printk: rebalance printk References: <55C9DB15.2070800@intel.com> <20150811181608.GA29819@kroah.com> In-Reply-To: <20150811181608.GA29819@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1916 Lines: 50 On 08/11/2015 02:16 PM, Greg Kroah-Hartman wrote: > On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote: >> From: Pan Xinhui >> >> printk can be called in any context, It's very useful to output debug >> info. >> >> But it might cause very bad issues on some special cases. For example, >> some driver hit errors, and it dumps many messages like reg values, etc. >> >> Sometimes, printk is called when irqs disabled. This is OKay if there is >> a few messages. But What would happen if many messages outputted by other >> drivers at same time. >> >> Here is the scenario. >> CPUA CPUB >> local_irq_save(flags); >> printk() >> while(..) { --> console_unlock >> printk(...); >> //hundreds or thousands loops >> } //all messages flushed out to consoles >> local_irq_restore(flags); >> > > Where are you seeing this type of scenario "in the wild"? Or is this > just a "debug/bringup hardware" issue? There have been problem reports of big machines getting soft-lockup/RCU stall warnings with serial console attached. I think SLES is carrying patches from Jan Kara to try to workaround this issue. > We shouldn't be ever stuck in a > printk that prints hundreds or thousands of loops, if so, we need to fix > the kernel code that does that, as we do have control over this. The loop referred to here is the loop in console_unlock(). Essentially what happens is one cpu can get trapped in the console_unlock() output loop; printk()'s from other cpus are only appending to the logbuf since they can't acquire the console_lock (which is owned by the one cpu trapped in the output loop). Regards, Peter Hurley -- 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/