Messages in this thread | | | Date | Wed, 9 Dec 2020 20:28:52 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t |
| |
On (20/12/09 12:00), Peter Zijlstra wrote: > > So another potential re-entry path is > > > > atomic_foo() > > spin_lock_irqsave(ATOMIC_HASH(v), flags) > > printk() > > prb() > > atomic_foo() > > spin_lock_irqsave(ATOMIC_HASH(v), flags) > > > > which can deadlock, in theory, if both atomics HASH to the same > > key (same spin_lock). > > Yep, but see the 'mostly' in the 'they mostly work'. Given the > limitiations of these architectures there's really only so much you can > do.
Right, agreed.
Nevertheless TIL that lockless printk buffer is not always lockless. Perhaps, people that work with those archs need to also know this. I haven't checked all the archs, but if, somehow, (IF) some of them can panic the system with the atomic hash entries locked, then on those archs new printk may not be able to flush-on-panic. Because while printk iterates logbuf it may HASH to the atomic hash table entry, that will never be unlocked. So there are some changes in atomic/printk department on those archs.
-ss
| |