Re: [PATCH v2 3/5] printk/nmi: Try hard to print Oops message in NMI context
From: Petr Mladek
Date: Tue Dec 08 2015 - 06:21:56 EST
> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/