Hello, Steven. On Wed, Jan 10, 2018 at 01:41:57PM -0500, Steven Rostedt wrote: > The issue with the solution you want to do with printk is that it can > break existing printk usages. As Petr said, people want printk to do two > things. 1 - print out data ASAP, 2 - not lock up the system. The two > are fighting each other. You care more about 2 where I (and others, > like Peter Zijlstra and Linus) care more about 1. > > My solution can help with 2 without doing anything to hurt 1. I'm not really sure why punting to a safe context is necessarily unacceptable in terms of #1 because there seems to be a pretty wide gap between printing useful messages synchronously and a system being caught in printk flush to the point where the system is not operational at all. > You are NACKing my solution because it doesn't solve this bug with net > console. I believe net console should be fixed. You believe that printk > should have a work around to not let net console type bugs occur. Which > to me is papering over the real bugs. As I wrote along with nack, I was more concerned with how this was pushed forward by saying that actual problems are not real. As for the netconsole part, sure, that can be one way, but please consider that the messages could be coming from network drivers, of which we have many and a lot of them aren't too high quality. Plus, netconsole is a separate path and network drivers can easily malfunction on memory allocation failures. Again, not a critical problem. We can decide either way but it'd be better to be generally safe (if we can do that reasonably), right? 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>
