Hello, Steven. On Fri, Jan 19, 2018 at 01:20:52PM -0500, Steven Rostedt wrote: > I was thinking about this a bit more, and instead of offloading a > recursive printk, perhaps its best to simply throttle it. Because the > problem may not go away if a printk thread takes over, because the bug > is really the printk infrastructure filling the printk buffer keeping > printk from ever stopping. > > This patch detects that printk is causing itself to print more and > throttles it after 3 messages have printed due to recursion. Could you > see if this helps your test cases? Sure, if this is the approach we're gonna take, I can try it with the silly test code and also try to reproduce the original problem and see whether this helps. I'm a bit worried tho because this essentially seems like "detect recursion, ignore messages" approach. netcons can have a very large surface for bugs. Suppressing those messages would make them difficult to debug. For example, all our machines have both serial console (thus the slowness) and netconsole hooked up and netcons code has had its fair share of issues. This would likely make tracking down those problems more challenging. Can we discuss pros and cons of this approach against offloading before committing to this? Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
