> Take the scenario where CPU1 is in the middle of a printk(), and is > holding its lock. > > CPU0 comes along and decides to trigger a NMI backtrace. This sends > a NMI to CPU1, which takes it in the middle of the serial console > output. > > With the existing solution, the NMI output will be written to the > temporary buffer, and CPU1 has finished handling the NMI it resumes > the serial console output, eventually dropping the lock. That then > allows CPU0 to print the contents of all buffers, and we get NMI > printk output. > > With this solution, as I understand it, we'll instead end up with > CPU1's printk trying to output direct to the console, and although > we've busted a couple of locks, we won't have busted the serial > console locks, so CPU1 will deadlock - and that will stop any output > what so ever. > > If this is correct, then the net result is that we go from NMI with > serial console producing output to NMI with serial console being > less reliable at producing output. You are right. I thought about it a lot and I think that the best solution is to avoid this patch at all. I guess that it will make Peter Zijlstra happy as well. Best Regards, Petr
