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: >>>> Hi Greg >>>> >>>> Actually, there is no change wrt sysrq handling. This note mentions that >>>> patch handles input overrun in all cases except sysrq. >>>> >>>> Peter Hurley felt this is such a use case that not everyone may run into. >>>> Hence he suggested to put this under CONFIG option. >>> >>> How would a distro / user know what to do here? Why would they ever >>> disable this? >> >> I would hope a distro would never enable it. > > Then it shouldn't be an option. > >>> 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. > >>> If it does cause problems, then a config option is also not the correct >>> response, as that's not how to manage this type of thing. >> >> What's the other method? Please don't say "module parameter". > > No, I will not say that at all :) > > If this breaks other hardware, I don't know what to suggest, but making > it an option is not good... > > Hm, I guess we can make it a build option, if you put a big description > in there saying to never enable it unless you know exactly what you are > doing, and have such messed up hardware. It's actually possible to trigger overruns on a standard serial console in any setup (overrun in the sense of dropped data, not overrun in the sense of buffer overflow). For example, while the console is spewing printk()'s (like during boot), simply paste big chunks of data from the remote. Some of that will likely be lost. This stems from the dual-channel design of the serial console; ie., the 'normal' channel is interrupts-enabled i/o to/from the tty device and the 'console' channel is interrupts-disabled output only to the remote. 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
