linux-kernel - Re: + lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160127061325.GA1538@X58A-UD3R>
Date:	Wed, 27 Jan 2016 15:13:26 +0900
From:	Byungchul Park <byungchul.park@....com>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	akpm@...ux-foundation.org, akinobu.mita@...il.com, jack@...e.cz,
	mingo@...nel.org, mm-commits@...r.kernel.org,
	linux-kernel@...r.kernel.org
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@...ux-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