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. thanks, 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
