Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1028160ybl; Fri, 10 Jan 2020 10:46:47 -0800 (PST) X-Google-Smtp-Source: APXvYqyiAEm+pLoBkJU+8+0d1ALBpv+3VZjzgiKQQ6Hqg+0oN4XZVm/PRACCvz2+pcxJPJ7d/crK X-Received: by 2002:aca:c68f:: with SMTP id w137mr3419963oif.179.1578682007367; Fri, 10 Jan 2020 10:46:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578682007; cv=none; d=google.com; s=arc-20160816; b=RFyNYzcmthPxp2XOeoJCaOMQmWdX8CLcfsk6nGwrcqoX1cnagRXOjoGeM5laMJzkXv lYplVqtWvB3C6Wsp4YMOKOgtHwxCKRhpc+rk3RS+oJPCKHYiWNLRdRXqIB5MNqDw4Est FKAxWFH5sjhN6bf5mw8r3Um8MbQJNxFCPMZMX9uu3BhSsMnmBdjrNRQIDtPF29dZ7mmd l4XJ54vLWVw0+gksA3FE7r+5h5/OffdHAO/VTyQGhK8uqnZWcKI/9N+DDg12hUE+0tmu iAPJd7A2LuPP09oDoTHnDu9JzOHZUR97DY/wRrhIqbmYaLXgPxAnBTIibqbguZR60rrz JIRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xT/BfY0Kh2PF96aPpkXV9wA49Je5zZWxGjY072EHJt0=; b=y9jPob3UxxoDm2Sy+BXRJFNl/CxqpF+XBz+wkfiv9dfzgWLUxv5R0C4upzu3jhewFS QSUlCoNatVYPjfoZKPo8mt8heZ6pegYLHcvJ1dZGcDn/7k3yUliWAKfsNT8q0aD2/buL HdYLpouTpXj3KvX9OfNMX5mIyKAEn9h8sjM88cWVQ0Qf4Hc0iSZQD3NPqzR28IUlpzxn iriq1JPofbUuK0noFOw0mUoE/RqcldX3BS6w6E27BAyNmHcJDfX68FETog+sC304xESD ll9NVNR0dYjSsCSx6yFmYJGPADGwkFtfPgbYjlYEJf73QYbPoiamjx3aeKSSISP6rWim EbdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 10si1410577ois.76.2020.01.10.10.46.35; Fri, 10 Jan 2020 10:46:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728556AbgAJSpf (ORCPT + 99 others); Fri, 10 Jan 2020 13:45:35 -0500 Received: from mga17.intel.com ([192.55.52.151]:52956 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728023AbgAJSpf (ORCPT ); Fri, 10 Jan 2020 13:45:35 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2020 10:45:35 -0800 X-IronPort-AV: E=Sophos;i="5.69,418,1571727600"; d="scan'208";a="218148092" Received: from agluck-desk2.amr.corp.intel.com ([10.3.52.68]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2020 10:45:34 -0800 Date: Fri, 10 Jan 2020 10:45:33 -0800 From: "Luck, Tony" To: Borislav Petkov Cc: Jan =?iso-8859-1?Q?H=2E_Sch=F6nherr?= , Yazen Ghannam , linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org Subject: Re: [PATCH v2 1/6] x86/mce: Take action on UCNA/Deferred errors again Message-ID: <20200110184533.GB20511@agluck-desk2.amr.corp.intel.com> References: <20200103150722.20313-1-jschoenh@amazon.de> <20200103150722.20313-2-jschoenh@amazon.de> <20200110095004.GD19453@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200110095004.GD19453@zn.tnic> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 10, 2020 at 10:50:04AM +0100, Borislav Petkov wrote: > On Fri, Jan 03, 2020 at 04:07:17PM +0100, Jan H. Sch?nherr wrote: > > Commit fa92c5869426 ("x86, mce: Support memory error recovery for both > > UCNA and Deferred error in machine_check_poll") added handling of UCNA > > and Deferred errors by adding them to the ring for SRAO errors. > > > > Later, commit fd4cf79fcc4b ("x86/mce: Remove the MCE ring for Action > > Optional errors") switched storage from the SRAO ring to the unified > > pool that is still in use today. In order to only act on the intended > > errors, a filter for MCE_AO_SEVERITY is used -- effectively removing > > handling of UCNA/Deferred errors again. > > > > Extend the severity filter to include UCNA/Deferred errors again. > > Also, generalize the naming of the notifier from SRAO to UC to capture > > the extended scope. > > > > Note, that this change may cause a message like the following to appear, > > as the same address may be reported as SRAO and as UCNA: > > > > Memory failure: 0x5fe3284: already hardware poisoned > > > > Technically, this is a return to previous behavior. > > > > Fixes: fd4cf79fcc4b ("x86/mce: Remove the MCE ring for Action Optional errors") > > Signed-off-by: Jan H. Sch?nherr > > Tony, ACK? Acked-by: Tony Luck > Also, do you want it in stable@ so that it gets backported? That's a tricky question. We have changing behavior (UCNA pages offlined, then a few kernel versions stopped doing this, now we are going to start doing it again. But is it really a _BUG_ that needs backporting to stable? I'm leaning towards "no it isn't". But could perhaps be convinced to change my mind if somebody has a good reason for wanting it there. Is there something to put in the tags to stop this being autoselected for backport because it has a Fixes: tag? > I'm wondering if in the memory_failure error() case, we should hand it > down to the remaining notifiers. > > Which also begs the question in light of this clumsy notifier counting: > > How about we have the default notifier *unconditionally* print the MCE? > I.e., if the error has reached it, it would print it. If not and some > other notifier consumed it, it will get handled differently. > > This way we won't need any special counting of notifiers and special > reg/unreg of notifiers etc. > > IOW, the logic would be: > > If something consumes the error, then it doesn't get printed. Notifier > does NOTIFY_STOP. > > If nothing consumes it or something looks at it and decides that it > should still get printed, then the last catch-all notifier callback does > that. I totally agree that counting notifiers is clumsy. Also less than ideal is the concept that any notifier on the chain can declare: "I fixed it" and prevent any other notifiers from even seeing it. Well the concept is good, but it is overused. I think we may do better with a field in the "struct mce" that is being passed to each where notifiers can wiggle some bits (semantics to be defined later) which can tell subsequent notifiers what sort of actions have been taken. E.g. the SRAO/UCNA notifier can say "I took this page offline" the dev_mcelog one can say "I think I handed to a process that has /dev/mcelog open" EDAC drivers can say "I decoded the address and printed something" CEC can say: "I silently counted this corrected error", or "error exceeded threshold and I took the page offline". The default notifier can print to console if nobody set a bit to say that the error had been somehow logged. -Tony