Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933416AbbHLB4Z (ORCPT ); Tue, 11 Aug 2015 21:56:25 -0400 Received: from mga09.intel.com ([134.134.136.24]:28221 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753064AbbHLB4X (ORCPT ); Tue, 11 Aug 2015 21:56:23 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,657,1432623600"; d="scan'208";a="746819427" Message-ID: <55CAA736.7030500@intel.com> Date: Wed, 12 Aug 2015 09:53:58 +0800 From: Pan Xinhui User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Greg Kroah-Hartman CC: "linux-kernel@vger.kernel.org" , Andrew Morton , pmladek@suse.cz, rostedt@goodmis.org, Tejun Heo , Peter Hurley , 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: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2243 Lines: 58 Hi, Greg thanks for your reply! On 2015年08月12日 02:16, 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? 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. > Sorry for misleading. these loops are just an example. In real world, there are many pr_info/pr_err when some drivers hit device errors to dump debug information. There is camera and sound test(multimedia test) in our side, we enable dynamic_debug to collect logs to fix some weird issues. sound driver will dump many reg/memory values, and camera will output a few logs with irqs disabled. So we hit this printk issues very frequently, and it blocks our tests indeed. Although we have other log-store methods, for example, pstore. But some boards are from customers, thanks to the security, every time boards powered up, memory are erased.... As printk is announced that it could be used in most context, So I prefer to enhance the stability of printk to handle such case. thanks xinhui > thanks, > > greg k-h > -- 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/