Messages in this thread | | | Date | Wed, 9 Dec 2020 12:00:42 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t |
| |
On Wed, Dec 09, 2020 at 07:46:13PM +0900, Sergey Senozhatsky wrote: > On (20/12/09 18:22), Sergey Senozhatsky wrote: > > > > > > Please put on your eye cancer gear and inspect the atomic implementation > > > of PA-RISC, Sparc32, feh, I forgot who else. > > > > > > Those SMP capable architectures are gifted with just one XCHG like > > > atomic instruction :/ Anyway, as said in the other email, they also > > > don't have NMIs so it mostly works. > > PeterZ, thanks for the pointers! > > > > Hmm, wow. OK, I definitely want to look further. > > > > When some CONFIG_DEBUG_FOO_BAR code wants to pr_err from prb->atomic_op > > on those archs then we deadlock in printk once again? > > E.g. arch/sparc/lib/atomic32.c > > spinlock_t __atomic_hash[ATOMIC_HASH_SIZE]; > atomic_foo() > { > spin_lock_irqsave(ATOMIC_HASH(v), flags) > ... > spin_unlock_irqrestore(ATOMIC_HASH(v), flags); > } > > 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.
| |