linux-kernel - Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160201014536.GA29804@X58A-UD3R>
Date:	Mon, 1 Feb 2016 10:45:36 +0900
From:	Byungchul Park <byungchul.park@....com>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	akpm@...ux-foundation.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org, akinobu.mita@...il.com, jack@...e.cz,
	peter@...leysoftware.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in
 the debug code

On Sun, Jan 31, 2016 at 09:40:08PM +0900, Sergey Senozhatsky wrote:
> On (01/29/16 21:54), Byungchul Park wrote:
> > Hello, Andrew
> > 
> > Please take this v5 patch instead of v2 patch, which you took. Or give your
> > opinion.
> > 
> > > It causes an infinite recursive cycle when using CONFIG_DEBUG_SPINLOCK,
> > > in the spin_dump(). Backtrace prints printk() -> console_trylock() ->
> > > do_raw_spin_lock() -> spin_dump() -> printk()... infinitely.
> > > 
> > > When the spin_dump() is called from printk(), we should prevent the
> > > debug spinlock code from calling printk() again in that context. It's
> > > reasonable to avoid printing "lockup suspected" which is just a warning
> > > message but it would cause a real lockup definitely.
> 
> 
> Hello Byungchul,
> 
> thanks for the patch and thanks for bringing this topic to discussion.
> let's not rush, if you don't mind, and return back for a bit. there are
> some serious cases (when we really would want to see a spin_dump output)
> that are broken.

Hello Sergey,

I reviewed your patch, and I hope your proposal to be merged so that the
problematic recursive cycle of printk() can be handled properly e.g. by
panic(). But avoiding an unnecessary recursive cycle is better than
panic(). What I handled in this patch is the warning case which causes
unnecessary lockup and don't need to happen. I think reseting lock or
zapping lock to print a kind of warning is not a good option, even though
your suggestion looks good in the unavoidable lockup case.

Thanks,
Byungchul

> 
> 	-ss