On Wed, Apr 29, 2015 at 04:48:01PM -0400, Peter Hurley wrote: > 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. I don't want this mess in the serial drivers :) But I do want hardware to work properly, and this seems like a case of trying to get the hardware to do something that it's not possible to do, which means there's not much we can do here... But I've forgotten what the original patch even looks like at this point in time, so who knows... greg k-h -- 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
