From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754738AbbGUKDk (ORCPT ); Tue, 21 Jul 2015 06:03:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52121 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753942AbbGUKDj (ORCPT ); Tue, 21 Jul 2015 06:03:39 -0400 Date: Tue, 21 Jul 2015 12:03:30 +0200 From: Borislav Petkov To: Ingo Molnar Cc: Tony Luck , X86-ML , LKML , ashok.raj@intel.com, gong.chen@linux.intel.com, Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH 1/7] x86/mce: Provide a lockless memory pool to save error records Message-ID: <20150721100330.GC32172@nazgul.tnic> References: <20150716073948.GA13909@nazgul.tnic> <1437032661-15521-1-git-send-email-bp@suse.de> <20150721082949.GA2367@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150721082949.GA2367@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2015 at 10:29:49AM +0200, Ingo Molnar wrote: > So this change appears to be completely unrelated to the stated purpose of this > patch? I'll carve it out into a separate patch. > Missing comma. Good point. > So I think the standard pattern for allocation failures with integer types is to > return -ENOMEM, not bool. This really matters, because: ... > here gen_pool_add() has an inverted logic, and they looks confusing. Lemme fix that. > Furthermore, why do we spell it 'mce_genpool' if the generic facility is spelling > it gen_pool? mce_gen_pool() it is. > So how are we going to report uncorrectable errors that forcibly > crash/panic the system if we cannot use printk? How will the admin > learn what was amiss? There's no change to that policy - we still panic for MCEs of MCE_PANIC_SEVERITY and higher. And mce_panic() does use printk() to dump that critical information. The gen_pool stuff is for MCEs for which the hw still raises an #MC exception but the severity code determines that we don't need to panic but do recovery action. However, we don't want to call printk() from the #MC exception handler since it is NMI-like atomic context and printk is not NMI-safe (yet). Those printks are issued later, in process context when we're done with the exception handler and recovery action. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --