On 04/29/2015 08:30 AM, Greg KH wrote: > On Wed, Apr 29, 2015 at 08:22:39AM -0400, Peter Hurley wrote: >> On 04/28/2015 02:17 PM, Greg KH wrote: >>> On Tue, Apr 28, 2015 at 10:44:31AM -0700, Prasad Koya wrote: >>> Please let's make this automatic, and work properly, no configuration >>> option should be needed, _IF_ this doesn't cause a problem for people >>> with normal systems. >> >> I feel the effort and trade-offs required to make this automatic and >> bullet-proof is simply not worth it. >> >> For example, new data that's received while in the middle of a >> printk() may trigger a GPF_ATOMIC memory allocation. >> >> That could cause real problems under the wrong circumstances. > > Then why have this "fix" in here at all? It sounds wrong. Greg, I'd like to make clear that while I've been trying to provide guidance for the patch, I'm not convinced this belongs in mainline (and I explained that upfront several months ago). Basically, the boundary conditions for stable behavior can easily be exceeded in several circumstances; this is one of them. So is trying to printk() a 1Kb log line over 9600 baud. That's nearly a second with interrupts off; good luck with that. While on one hand, this seems like a flaw that we should be fixing, on the the other hand, it is self-evident that serial console is not the solution to every problem. I'm sure most kernel developers have experienced losing control of the machine from console spew that never ends; which is why ftrace can be so useful. IOW, if you don't want this mess in the serial drivers, that's ok by me. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
