Messages in this thread | | | Date | Wed, 9 Dec 2020 19:46:13 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t |
| |
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).
I wonder what else am I missing.
-ss
| |