Received: by 10.223.164.221 with SMTP id h29csp839587wrb; Wed, 11 Oct 2017 10:11:01 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBvXcWdVY7jm2VEhzyh4UPNLDLuUHidQauAAXLcppC950nsTQoCVlTCQDY7OBsIW0+t+fys X-Received: by 10.98.10.133 with SMTP id 5mr235558pfk.346.1507741861846; Wed, 11 Oct 2017 10:11:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507741861; cv=none; d=google.com; s=arc-20160816; b=l/PZ6jdOIZFAK7Ngnf7ZjrjWjtyMBQ8h7nsL1pE56prsnRCbDkU5HRUa6wPnuFlxOH c8YdeX8cJxcT0O6YGw15GxMiPXSo41VWEzvJuxHk6SCeBFd1gdYyC8FEUP668xVTZ78F QwuN41pxICD2e7u6MUD3MqLa/L6kue5NXrGLMHKv3v5wQKVbdH5jh3IFkohT06umMp6R abAmscAl4daeAQdvUYBY4fSxgMwJ0hRZIn9Uu/39mHL5nhGzEu6sBOXYCBbB23V4qTYM rrSeKISTECq1KS1rmE0UUxyrzRV8IC0VXjMg3Ojevhmh4x/nOUcFydIwlpt7wvVi8yuZ 7eDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:arc-authentication-results; bh=WR9PkR/Q+N1nVVLhuAtV1CY3t8whyf+PmE4/TjpO3L4=; b=jjh7I8dCAd5Ev5gSBscfpf7z2XZDnzFxSmVBXYA4r5qUo5AYUXnzitNTENONNnpwaM ocxqC9vj+re6PlLZFwCOv4xxyzIrNEGzlRT6E17O6M/3ugFurB4Zbx4QhDdpuxVuGW13 dNrxkd/PajNmO50x8/se9wiEtAifE6S8Gt/pawZV/9dIPd6vhkX+0SiBR7cQlvZb8/4X acZgW/R+TTk+MWfVOp4qwjsmsIoJOcvFzkjZwO17h05+wz2cLbNzPXoUdjTQdi8KS3Yc OJVkukzIEh2DvdR0ONkq4J0uMtTW0zmWKcK3k3XknDtVWae7BgA1FEhBXVCH0xVgjhY2 fbkw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g16si288120pfd.472.2017.10.11.10.10.44; Wed, 11 Oct 2017 10:11:01 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756931AbdJKRJw (ORCPT + 99 others); Wed, 11 Oct 2017 13:09:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:46048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbdJKRJv (ORCPT ); Wed, 11 Oct 2017 13:09:51 -0400 Received: from localhost (unknown [69.71.4.159]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B1798218CA; Wed, 11 Oct 2017 17:09:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1798218CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=helgaas@kernel.org Date: Wed, 11 Oct 2017 12:09:46 -0500 From: Bjorn Helgaas To: Tyler Baicar Cc: bhelgaas@google.com, jonathan.derrick@intel.com, keith.busch@intel.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PCI/AER: don't call recovery process for correctable errors Message-ID: <20171011170946.GI25517@bhelgaas-glaptop.roam.corp.google.com> References: <1503940184-29423-1-git-send-email-tbaicar@codeaurora.org> <20171002231903.GE5407@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 11, 2017 at 10:37:47AM -0400, Tyler Baicar wrote: > On 10/2/2017 7:19 PM, Bjorn Helgaas wrote: > >On Mon, Aug 28, 2017 at 11:09:44AM -0600, Tyler Baicar wrote: > >>Correctable errors do not need any software intervention, so > >>avoid calling into the software recovery process for correctable > >>errors. > >> > >>Signed-off-by: Tyler Baicar > >>--- > >> drivers/pci/pcie/aer/aerdrv_core.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >>diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c > >>index b1303b3..4765c11 100644 > >>--- a/drivers/pci/pcie/aer/aerdrv_core.c > >>+++ b/drivers/pci/pcie/aer/aerdrv_core.c > >>@@ -626,7 +626,8 @@ static void aer_recover_work_func(struct work_struct *work) > >> continue; > >> } > >> cper_print_aer(pdev, entry.severity, entry.regs); > >>- do_recovery(pdev, entry.severity); > >>+ if (entry.severity != AER_CORRECTABLE) > >>+ do_recovery(pdev, entry.severity); > >I think this is fine, and it mirrors what is done in > >handle_error_source(). > > > >But I want to converge the APEI path and the "native" AER path, so as > >one tiny step in that direction, can you look into doing this test > >once, e.g., move the test from handle_error_source() into > >do_recovery(), where one test will handle both paths? > > I've looked into this and it seems there is still going to need to > be two versions of this check. The native AER path goes through > handle_error_source() and for correctable errors requires the write > to PCI_ERR_COR_STATUS, but the APEI path does not require this > write. I could move this check to the beginning of do_recovery() so > it returns right away for correctable errors and remove the else > line in handle_error_source() so it always calls into do_recovery(). > That doesn't seem like a very clean solution though since then there > are still two checks for correctable errors and now we're calling > into do_recovery() in both cases for nothing :) The PCI_ERR_COR_STATUS thing is part of what I see as the problem here. IMHO, the native AER path should collect up the log registers (and do any acknowledgement, e.g., writing PCI_ERR_COR_STATUS) *before* entering the common path. In other words, the Linux code in the native part of AER should be functionally the same as the BIOS code that implements the APEI path. This is a bit of restructuring in the Linux AER code. I haven't looked enough to know how much. If it's impractical, it's impractical. I thought this might be an opportunity for a tiny step in that direction, but if it's not, I guess that's OK. Bjorn From 1580972415148155031@xxx Wed Oct 11 14:39:47 +0000 2017 X-GM-THRID: 1576995657442027352 X-Gmail-Labels: Inbox,Category Forums