Messages in this thread | | | Date | Wed, 27 Jan 2016 15:13:26 +0900 | From | Byungchul Park <> | Subject | Re: + 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
| |