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 10:20:04 +0800 [thread overview]
Message-ID: <55CAAD54.4060109@intel.com> (raw)
In-Reply-To: <20150812020406.GA3383@kroah.com>
On 2015年08月12日 10:04, Greg Kroah-Hartman wrote:
> On Wed, Aug 12, 2015 at 09:53:58AM +0800, Pan Xinhui wrote:
>> 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.
>
> That's not good, they should use dev_dbg() for that instead.
>
Agree, We changed some codes to use dev_dbg(). But some errors still need be outputted immediately.
But when we enabled dynamic debug. there is not much difference... printk issue still hit.
>> 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.
>
> Maybe those memory value dumps should be done through debugfs instead of
> printk?
>
These reg/memory runtime values must be outputted in time, they have changed at any time..
>> 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.
>
> Stability is nice, but using printk for things it was never ment to be
> used for, isn't good. Especially if you are forced to add additional
> complexity to the printk logic just for these corner cases that no one
> uses :)
>
printk is very good, it does work in very complex context, including in interrupt, etc.
However if we could make it better, then why not :)
My patch is a little complex. Sorry for that.
I would try to work out V2.
thanks
xinhui
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2015-08-12 2:22 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
2015-08-12 2:04 ` Greg Kroah-Hartman
2015-08-12 2:20 ` Pan Xinhui [this message]
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=55CAAD54.4060109@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.