Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1318690

Re: + lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch added to -mm tree

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: +  lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch  added to -mm tree Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-27 02:20 +0100
  Re: +  lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch  added to -mm tree Byungchul Park <byungchul.park@lge.com> - 2016-01-27 07:20 +0100

csiph-web