lkml.org 
[lkml]   [2020]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-12-09 11:50    [W:0.091 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site