Messages in this thread | | | From | John Ogness <> | Subject | Re: [RFC PATCH v1 20/25] serial: 8250: implement write_atomic | Date | Fri, 08 Mar 2019 05:17:36 +0100 |
| |
On 2019-03-08, John Ogness <john.ogness@linutronix.de> 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
| |