Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1799259pxu; Thu, 8 Oct 2020 23:09:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvEn/mi1BndZBcgRI1hEpb5IjoY7DqrnyWkxy5jQIteJIkNOx+KxZaLVHZvEhGyOd6GLrZ X-Received: by 2002:a50:d84f:: with SMTP id v15mr12345711edj.61.1602223756787; Thu, 08 Oct 2020 23:09:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602223756; cv=none; d=google.com; s=arc-20160816; b=FvfKpPOhuXxZf9AeUEVtQI4KuSGeFgTagwynXL8bAxKwCCc8XldzM0otFQrJusXrzz iXbMHNvOVoc00K7ogTKmcb2ld+PuoeILXZnLQB/fV4Im0PQxCj1+H+fMTesGDJNpfcLQ orU3N5djU9stchla2U6mlJ0rYvcfJhiq/slG/hUVTVIQLle6YhJ7c2ZrCZIvAxS837LX vwSPRaOretnSWhnC/LQ16pxc/UzL67ZrnULIhGNxU/x1C6bge3pl91ZUCyPqMwTWLJQO T1dvS6vrdo6mNpoERndPhzYBIoJeXiPmKnvB88iD8b9jP6ZgfgpTnJvTTCtjCgSKq4qa R/3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=jEtxmky6QVPyrxEeI8FJbI4JSkuMdz9PQ5TCXyY5IiE=; b=q97/bDVUBQ+Edyg9IatyUvKOlL1Nmfxvmororv7AAsTrE/lLfxLAgdx/Vpm1bLHIIY ENZhDc6DvT/hm08NkstTjdCs3IDZ4MYv5uoBdVfWT2RKWo0C19R4rzMtIQtC9JZR2V2S QzKCAb4CJhxsK5crkF3psR9dC1VLDsXsuT+d6VTThjkaQAWX1aB5TLb+sdPQeEi+I3AL q3Gof9VmL3obf+dvmGUH0nbu3tVyauz1S/Xk1dlINWlCancbGixl25zY3jjqlqV8Z4Ur gqLHc7fLCNlrZcGnLC0ICobq4Yvz27pl5ouiksr+DK9Ooyg3+V0DtQ/AcmAjoR6S0ffF SKBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id b11si6692558ejz.631.2020.10.08.23.08.53; Thu, 08 Oct 2020 23:09:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1731545AbgJIDqW (ORCPT + 99 others); Thu, 8 Oct 2020 23:46:22 -0400 Received: from mga07.intel.com ([134.134.136.100]:45009 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726386AbgJIDqW (ORCPT ); Thu, 8 Oct 2020 23:46:22 -0400 IronPort-SDR: sAH5wkdwKvr49s5rBqK+N47Gs7teTsZQv2Ysu2OoOOWqtREX4XJUAXbtJpAOuaTbHvOzwffp0N tUIkBt2RirGg== X-IronPort-AV: E=McAfee;i="6000,8403,9768"; a="229624589" X-IronPort-AV: E=Sophos;i="5.77,353,1596524400"; d="scan'208";a="229624589" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 20:46:20 -0700 IronPort-SDR: FpjiBfNdoN7koPf8fXg6fDEgVMPctALFUvERJN1oVb0s+aBw6dMeqtgXHkOelCOvEep486C0DU HCiG3AAiwEwA== X-IronPort-AV: E=Sophos;i="5.77,353,1596524400"; d="scan'208";a="462045333" Received: from otc-nc-03.jf.intel.com (HELO otc-nc-03) ([10.54.39.36]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 20:46:20 -0700 Date: Thu, 8 Oct 2020 20:46:14 -0700 From: "Raj, Ashok" To: Hedi Berriche Cc: Kuppuswamy Sathyanarayanan , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Russ Anderson , Bjorn Helgaas , Keith Busch , Joerg Roedel , stable@kernel.org, Ashok Raj Subject: Re: [PATCH v1 1/1] PCI/ERR: don't clobber status after reset_link() Message-ID: <20201009034614.GB60852@otc-nc-03> References: <20201009025251.2360659-1-hedi.berriche@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201009025251.2360659-1-hedi.berriche@hpe.com> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 09, 2020 at 03:52:51AM +0100, Hedi Berriche wrote: > Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()") > changed pcie_do_recovery() so that status is updated with the return > value from reset_link(); this was to fix the problem where we would > wrongly report recovery failure, despite a successful reset_link(), > whenever the initial error status is PCI_ERS_RESULT_DISCONNECT or > PCI_ERS_RESULT_NO_AER_DRIVER. > > Unfortunately this breaks the flow of pcie_do_recovery() as it prevents What is the reference to "this breaks" above? > the actions needed when the initial error is PCI_ERS_RESULT_CAN_RECOVER > or PCI_ERS_RESULT_NEED_RESET from taking place which causes error > recovery to fail. > > Don't clobber status after reset_link() to restore the intended flow in > pcie_do_recovery(). > > Fix the original problem by saving the return value from reset_link() > and use it later on to decide whether error recovery should be deemed > successful in the scenarios where the initial error status is > PCI_ERS_RESULT_{DISCONNECT,NO_AER_DRIVER}. I would rather rephrase the above to make it clear what is being proposed. Since the description seems to talk about the old problem and new solution all mixed up. > > Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()") > Signed-off-by: Hedi Berriche > Cc: Russ Anderson > Cc: Kuppuswamy Sathyanarayanan > Cc: Bjorn Helgaas > Cc: Ashok Raj > Cc: Keith Busch > Cc: Joerg Roedel > > Cc: stable@kernel.org # v5.7+ > --- > drivers/pci/pcie/err.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > index c543f419d8f9..dbd0b56bd6c1 100644 > --- a/drivers/pci/pcie/err.c > +++ b/drivers/pci/pcie/err.c > @@ -150,7 +150,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > pci_channel_state_t state, > pci_ers_result_t (*reset_link)(struct pci_dev *pdev)) > { > - pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER; > + pci_ers_result_t post_reset_status, status = PCI_ERS_RESULT_CAN_RECOVER; why call it post_reset_status? > struct pci_bus *bus; > > /* > @@ -165,8 +165,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > pci_dbg(dev, "broadcast error_detected message\n"); > if (state == pci_channel_io_frozen) { > pci_walk_bus(bus, report_frozen_detected, &status); > - status = reset_link(dev); > - if (status != PCI_ERS_RESULT_RECOVERED) { > + post_reset_status = reset_link(dev); > + if (post_reset_status != PCI_ERS_RESULT_RECOVERED) { > pci_warn(dev, "link reset failed\n"); > goto failed; > } > @@ -174,6 +174,13 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > pci_walk_bus(bus, report_normal_detected, &status); > } > > + if ((status == PCI_ERS_RESULT_DISCONNECT || > + status == PCI_ERS_RESULT_NO_AER_DRIVER) && > + post_reset_status == PCI_ERS_RESULT_RECOVERED) { > + /* error recovery succeeded thanks to reset_link() */ > + status = PCI_ERS_RESULT_RECOVERED; > + } > + > if (status == PCI_ERS_RESULT_CAN_RECOVER) { > status = PCI_ERS_RESULT_RECOVERED; > pci_dbg(dev, "broadcast mmio_enabled message\n"); > -- > 2.28.0 >