linux-kernel - [PATCH] PCI AER: handle pci_cleanup_aer_uncorrect_error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1386949306-30601-1-git-send-email-betty.dall@hp.com>
Date:	Fri, 13 Dec 2013 08:41:46 -0700
From:	Betty Dall <betty.dall@...com>
To:	rjw@...ysocki.net, bhelgaas@...gle.com
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	Betty Dall <betty.dall@...com>
Subject: [PATCH] PCI AER: handle pci_cleanup_aer_uncorrect_error_status() in firmware first mode

There are three functions exported from aerdrv_core.c that could be
called when the system is in firmware first mode:
pci_enable_pcie_error_reporting(), pci_disable_pcie_error_reporting, and
pci_cleanup_aer_uncorrect_error_status(). The first two functions check if
we are in firmware first mode and return immediately.
pci_cleanup_aer_uncorrect_error_status() does not check firmware first
mode. The problem is that all of these functions should not access the AER
registers in firmware first mode because the firmware has not granted OS
control of the AER registers through the _OSC. Many drivers call this
function in their pci_error_handlers in firmware first mode.

The fix is to change pci_cleanup_aer_uncorrect_error_status() to check
firmware first mode before accessing the AER registers. If it is in firmware
first mode, return 0. I considered returning -EIO, but decided the status
has been cleaned up appropriately for firmware first. Returning 0 also avoids
an error message. Not many places check the return of this function, and the
ones that do, print an error message and continue such as:
   err = pci_cleanup_aer_uncorrect_error_status(pdev);
   if (err) {
       dev_err(&pdev->dev,
           "pci_cleanup_aer_uncorrect_error_status failed 0x%0x\n",
            err); /* non-fatal, continue */
   }
That error message is how I found this problem, and it is not applicable
for the firmware first recovery path.

Signed-off-by: Betty Dall <betty.dall@...com>
---

 drivers/pci/pcie/aer/aerdrv_core.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
index b2c8881..1f60408 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -62,6 +62,9 @@ int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
 	int pos;
 	u32 status;
 
+	if (pcie_aer_get_firmware_first(dev))
+		return 0;
+
 	pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
 	if (!pos)
 		return -EIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/