On 2019-03-08, John Ogness <john.ogness@xxxxxxxxxxxxx> wrote: > If the ringbuffer was fully lockless, we should be able to have > per-console CPU-reentrant spin locks as long as the ordering is > preserved, which I expect shouldn't be a problem. If any NMI context > needed a spin lock for its own purposes, it would need to use the > CPU-reentrant spin lock of the first console so as to preserve the > ordering in case of a panic. This point is garbage. Sorry. I do not see how we could safely have multiple CPU-reentrant spin locks. Example of a deadlock: CPU0 CPU1 printk printk console2.lock console1.lock NMI NMI printk printk console1.lock console2.lock >> ... it should not be a common lock for the ring buffer and all >> consoles. > > If the ring buffer becomes fully lockless, then we could move to > per-console CPU-reentrant spin locks. A fully lockless ring buffer will reduce the scope of the one, global CPU-reentrant spin lock. But I do not see how we can safely have multiple of these. If it is part of printk, it is already implicitly on every line of code. John Ogness