linux-kernel - Re: [PATCH] Avoid dead lock of console related locks in panic case

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:	Fri, 30 Nov 2012 14:30:23 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Seiji Aguchi <seiji.aguchi@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"joe@...ches.com" <joe@...ches.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"kay@...y.org" <kay@...y.org>,
	"jim.cromie@...il.com" <jim.cromie@...il.com>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
	"jason.wessel@...driver.com" <jason.wessel@...driver.com>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: Re: [PATCH] Avoid dead lock of console related locks in panic case

On Fri, 30 Nov 2012 17:11:07 +0000
Seiji Aguchi <seiji.aguchi@....com> wrote:

> If one cpu ,which is taking a logbuf_lock or console_sem, 
> receive IPI/NMI from a panicked cpu via smp_send_stop(),
> the panicked cpu hangs up in subsequent kmsg_dump()/printk()
> because logbuf_lock and console_sem are taken in the function calls.
> 
> This causes a console blank and users can't see panic messages.
> 
> [Solution]
> 
> this patch introduces a logic initializing logbuf_lock and console_sem
> just after smp_send_stop() to avoid dead locks above.

That is one nasty looking patch :(

- Makes the logic in this area even more twisty and complex, when
  what we need to do is to simplify it

- Reinitialises in-use locks

- Gives the boolean variable "yes" three states, but didn't rename
  that variable to something appropriate.

- Passes yes==2 into s390's unsuspecting bust_spinlocks() implementation.


Let's step back a bit.  Please identify with great specificity the code
sites which are stopping other CPUs before taking locks which those
other CPUs might have been holding.

Then let's see what we can do to fix up the callers, instead of trying
to tidy up after they have made this mess.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/