From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753910AbbCFJMR (ORCPT ); Fri, 6 Mar 2015 04:12:17 -0500 Received: from TYO201.gate.nec.co.jp ([210.143.35.51]:48907 "EHLO tyo201.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145AbbCFJMH convert rfc822-to-8bit (ORCPT ); Fri, 6 Mar 2015 04:12:07 -0500 From: Naoya Horiguchi To: Borislav Petkov CC: "Luck, Tony" , Prarit Bhargava , Vivek Goyal , "linux-kernel@vger.kernel.org" , Junichi Nomura , Kiyoshi Ueda Subject: Re: [PATCH v6] x86: mce: kexec: switch MCE handler for kexec/kdump Thread-Topic: [PATCH v6] x86: mce: kexec: switch MCE handler for kexec/kdump Thread-Index: AQHQV7mGuatubJdfLkWCzK34yKOQmJ0OilyAgAAJ0gA= Date: Fri, 6 Mar 2015 09:09:30 +0000 Message-ID: <20150306090930.GA14982@hori1.linux.bs1.fc.nec.co.jp> References: <1425373306-26187-1-git-send-email-n-horiguchi@ah.jp.nec.com> <3908561D78D1C84285E8C5FCA982C28F329F5837@ORSMSX114.amr.corp.intel.com> <20150304074117.GA30501@hori1.linux.bs1.fc.nec.co.jp> <3908561D78D1C84285E8C5FCA982C28F329F835A@ORSMSX114.amr.corp.intel.com> <20150305012447.GA16001@hori1.linux.bs1.fc.nec.co.jp> <20150305064509.GA16012@hori1.linux.bs1.fc.nec.co.jp> <20150305085735.GE3915@pd.tnic> <20150305093752.GA11764@hori1.linux.bs1.fc.nec.co.jp> <20150306025911.GA3619@hori1.linux.bs1.fc.nec.co.jp> <20150306083421.GD3514@pd.tnic> In-Reply-To: <20150306083421.GD3514@pd.tnic> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.6] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 06, 2015 at 09:34:21AM +0100, Borislav Petkov wrote: > On Fri, Mar 06, 2015 at 02:59:13AM +0000, Naoya Horiguchi wrote: > > From 8890e9976c525a4b480bf5f86008641688de8c11 Mon Sep 17 00:00:00 2001 > > From: Naoya Horiguchi > > Date: Fri, 6 Mar 2015 11:52:10 +0900 > > Subject: [PATCH v6] x86: mce: kexec: switch MCE handler for kexec/kdump > > > > kexec disables (or "shoots down") all CPUs other than a crashing CPU before > > entering the 2nd kernel. But the MCE handler is still enabled after that, > > so if MCE happens and broadcasts over the CPUs after the main thread starts > > the 2nd kernel (which might not initialize MCE device yet, or might decide > > not to enable it,) MCE handler runs only on the other CPUs (not on the main > > thread,) leading to kernel panic with MCE synchronization. The user-visible > > effect of this bug is kdump failure. > > > > Our standard MCE handler do_machine_check() assumes some about system's > > status and it's hard to alter it to cover kexec/kdump context, so let's add > > another kdump-specific one and switch to it. > > > > Note that this problem exists since current MCE handler was implemented in > > 2.6.32, and recently commit 716079f66eac ("mce: Panic when a core has reached > > a timeout") made it more visible by changing the default behavior of the > > synchronization timeout from "ignore" to "panic". > > > > Signed-off-by: Naoya Horiguchi > > ... > > > +static void machine_check_under_kdump(struct pt_regs *regs, long error_code) > > +{ > > + struct mce m = {}; > > + char *msg = NULL; > > + char *nmsg = NULL; > > + int i; > > + int worst = 0; > > + int severity; > > + int ret; > > if you do here > > if (mce_cfg.disabled) > return; > > you can use the simple rdmsrl variants and not the _safe() ones with > exception handling. I'm not sure why that works, could you elabroate it? I feel that we need some comment about why it's OK to use rdmsrl_safe() variant *only* in mce_rdmsrl() (other MCE registers is accessed via rdmsrl(),) which seems not clear to me from reading current code and git history. Thanks, Naoya Horiguchi