lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: + lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch added to -mm tree
On Wed, Jan 27, 2016 at 10:14:54AM +0900, Sergey Senozhatsky wrote:
> On (01/26/16 16:12), akpm@linux-foundation.org wrote:
> [..]
> > There is an infinite recursive cycle when using CONFIG_DEBUG_SPINLOCK, in
> > spin_dump(). Backtrace prints printk() -> console_trylock() ->
> > do_raw_spin_lock() -> spin_bug() -> spin_dump() -> printk()...
> > infinitely.
>
> is it even possible to lockup on a semaphore's spin_lock?
>
> int down_trylock(struct semaphore *sem)
> {
> unsigned long flags;
> int count;
>
> raw_spin_lock_irqsave(&sem->lock, flags);
> ^^^^ here?

Yes.

> under what circumstances and why it should be silenced? a memory corruption?
> or is it the 'logbuf_lock' spin_lock that was meant to be in the report?

Backtracing said it's console_sem.lock. But as you said, logbuf_lock can
cause same lockup when trying printk() in printk().

> so if the CPU that owns the spin_lock somehow managed to keep it forever
> (due to a memory corruption... or something has powered off the cpu
> core???) -- then _this is_ the problem, not the fact that other CPUs will
> not lock the spin_lock anymore.
>
> so I don't think this patch does the right thing, sorry.

I agree with you.

thanks,
byungchul

\
 
 \ /
  Last update: 2016-01-27 08:01    [W:0.039 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site