From: Pan Xinhui <xinhuix.pan@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
pmladek@suse.cz, rostedt@goodmis.org, Tejun Heo <tj@kernel.org>,
Peter Hurley <peter@hurleysoftware.com>,
Joe Perches <joe@perches.com>,
hch@lst.de, viro@zeniv.linux.org.uk,
Vasily Averin <vvs@virtuozzo.com>
Subject: Re: [PATCH] printk: rebalance printk
Date: Wed, 12 Aug 2015 09:53:58 +0800 [thread overview]
Message-ID: <55CAA736.7030500@intel.com> (raw)
In-Reply-To: <20150811181608.GA29819@kroah.com>
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 <xinhuix.pan@intel.com>
>>
>> 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
>
next prev parent reply other threads:[~2015-08-12 1:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 11:23 [PATCH] printk: rebalance printk Pan Xinhui
2015-08-11 11:34 ` Pan Xinhui
2015-08-11 12:00 ` Peter Hurley
2015-08-12 1:35 ` Pan Xinhui
2015-08-11 18:16 ` Greg Kroah-Hartman
2015-08-12 1:53 ` Pan Xinhui [this message]
2015-08-12 2:04 ` Greg Kroah-Hartman
2015-08-12 2:20 ` Pan Xinhui
2015-08-12 12:31 ` Peter Hurley
2015-08-13 2:16 ` Pan Xinhui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55CAA736.7030500@intel.com \
--to=xinhuix.pan@intel.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox