From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423266AbcFGVEf (ORCPT ); Tue, 7 Jun 2016 17:04:35 -0400 Received: from mail.skyhub.de ([78.46.96.112]:51647 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161158AbcFGVEd (ORCPT ); Tue, 7 Jun 2016 17:04:33 -0400 Date: Tue, 7 Jun 2016 23:04:27 +0200 From: Borislav Petkov To: "Luck, Tony" Cc: linux-edac , Yazen Ghannam , X86 ML , LKML Subject: Re: [RFC PATCH 1/4] RAS: Add a Corrected Errors Collector Message-ID: <20160607210427.GF1152@pd.tnic> References: <1465318345-22043-1-git-send-email-bp@alien8.de> <1465318345-22043-2-git-send-email-bp@alien8.de> <20160607181109.GA23770@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160607181109.GA23770@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote: > Is there a reason that we need to call the ce_add_elem() inline > here instead of having it just register on the mce_notifier chain? > This series just cleaned out all the /dev/mcelog special code from > here, and you are adding something back before the ink is dry on > that change. > > I'm also strongly divided about whether this corrected error > handler should be allowed to preempt anything else even seeing > the error. Well, so this is the main reason for adding the CEC: not to disturb users with random CECC errors which might happen a couple of times due to alpha particles and then never again. I.e., address all those sporadic bursts of correctable errors which don't mean that the hw is going faulty. If the CEC consumes the error and does the leaky bucket of "forgetting" about it after a while and after no more of that same PFN triggers errors, then we do that silently and do not scare users. Yeah, they think their hw is broken and whether they should start swapping things. And then there's the aspect of soft-offlining PFNs when the error threshold has been reached. I don't think we have had any automatic recovery actions wrt errors so far without external agents. > Argument for: > Lonely corrected errors are "No Big Deal"(TM). Just counting them > and moving on is a good thing. Yap, exactly. > Arguments against: > 1) We may miss out on a one-time opportunity to get extra information > (from acpi_extlog.c). > 2) I think this subverts our CMCI storm detection and mitigation code? ...and we can address that by adding "ras=cec_doesnt_consume_errors" or somesuch so that the rest of the chain sees them too. I think we can be pretty flexible about it. And again, my main angle is the "do not disturb users unnecessarily". > We could make the chain more caller friendly by adding a filter > argument so users could say "just tell me about memory errors" > (currently each of the EDAC drivers has inline code to do the same > as "memory_error(m) && mce_usable_address(m)") Sure, that too. And it can work on any system without the need for an EDAC driver. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.