Re: [PATCH] printk: rebalance printk

[Pan Xinhui]

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@xxxxxxxxx>
>>
>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/