linux-kernel - Re: [PATCH] x86, MCE: Flesh out when to panic comment

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: <alpine.LNX.2.00.1405261250230.12047@pobox.suse.cz>
Date:	Mon, 26 May 2014 12:51:10 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Borislav Petkov <bp@...en8.de>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andi Kleen <andi@...stfloor.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	"Luck, Tony" <tony.luck@...el.com>
Subject: Re: [PATCH] x86, MCE: Flesh out when to panic comment

On Mon, 26 May 2014, Borislav Petkov wrote:

> On Wed, May 21, 2014 at 03:13:54PM -0700, H. Peter Anvin wrote:
> > Seems like a comment would be in order, though.
> 
> ---
> From: Borislav Petkov <bp@...e.de>
> Subject: [PATCH] x86, MCE: Flesh out when to panic comment
> 
> Recent discussion (link below) showed that it is not really clear what
> appropriate recovery actions we're taking when in a machine check
> exception. Flesh out the comment which was explaining that with more
> detail.
> 
> Suggested-by: "H. Peter Anvin" <hpa@...or.com>
> Cc: Tony Luck <tony.luck@...el.com>
> Link: http://lkml.kernel.org/r/CALCETrXudJ8BkNF_M-r4O40XLN%2BPnZ5TOZw0P7N4kqo3qngzyg@mail.gmail.com
> Signed-off-by: Borislav Petkov <bp@...e.de>
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index 68317c80de7f..9f070339b09f 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1151,10 +1151,14 @@ void do_machine_check(struct pt_regs *regs, long error_code)
>  		no_way_out = worst >= MCE_PANIC_SEVERITY;
>  
>  	/*
> -	 * At insane "tolerant" levels we take no action. Otherwise
> -	 * we only die if we have no other choice. For less serious
> -	 * issues we try to recover, or limit damage to the current
> -	 * process.
> +	 * At insane "tolerant" levels we take no action. Otherwise we only die
> +	 * if we have no other choice. Which means, we're definitely going to
> +	 * panic on unrecoverable, uncontainable errors which would otherwise
> +	 * influence machine state and/or cause any type of corruption. The
> +	 * decision what do to is done by mce_severity().
> +	 *
> +	 * For less serious issues we try to recover, or limit damage to the
> +	 * current process.
>  	 */

I think the comment is still not explaining the big part of what the 
discussion was about -- i.e. if it was in kernel context, we always panic.

-- 
Jiri Kosina
SUSE Labs
--
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/