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]
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

Powered by blists - more mailing lists