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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180209120415.17590-2-vigneshr@ti.com>
Date:   Fri, 9 Feb 2018 17:34:13 +0530
From:   Vignesh R <vigneshr@...com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jingoo Han <jingoohan1@...il.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>
CC:     Kishon Vijay Abraham I <kishon@...com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Niklas Cassel <niklas.cassel@...s.com>,
        <linux-omap@...r.kernel.org>, <linux-pci@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Vignesh R <vigneshr@...com>
Subject: [PATCH 1/3] Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"

Since commit 06e15e6883bed ("PCI: dwc: Clear MSI interrupt status after
it is handled, not before"), MSI IRQ status in PCIE_MSI_INTR0_STATUS
register is cleared after calling EP's IRQ handler.
But, MSI IRQs in case of PCIe are bit like edge interrupts. If a
another MSI IRQ is raised and the end of current EP's IRQ handler call
but before clearing the MSI IRQ status in PCIE_MSI_INTR0_STATUS register
then the new MSI IRQ is lost.

This issue has been observed in case of USB-Ethernet adapter connected
to PCIe USB card running iperf3 test. iperf3 client stalls after
sometime as reported here[1]. This is because XHCI raises MSI IRQ at the
end of its IRQ handler but before PCIe driver has cleared its status
in PCIE_MSI_INTR0_STATUS register. Hence, the new IRQ is never
registered by PCIe designware core. Since, XHCI does not raise any more
IRQs until the previous one is handled, it leads to a stall in
communication.
Therefore driver should always clear the MSI IRQ status in
PCIE_MSI_INTR0_STATUS before calling EP's IRQ handler. This make sure
that DW PCIe core catches new IRQ raised during the call to EP's IRQ
handler

[1] https://lkml.kernel.org/r/BN6PR18MB124994D85EAC4B5B1AD5EC56866E0@BN6PR18MB1249.namprd18.prod.outlook.com

Signed-off-by: Vignesh R <vigneshr@...com>
---
 drivers/pci/dwc/pcie-designware-host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c b/drivers/pci/dwc/pcie-designware-host.c
index 8de2d5c69b1d..c29cbcd430f4 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -68,9 +68,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
 		while ((pos = find_next_bit((unsigned long *) &val, 32,
 					    pos)) != 32) {
 			irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
-			generic_handle_irq(irq);
 			dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
 					    4, 1 << pos);
+			generic_handle_irq(irq);
 			pos++;
 		}
 	}
-- 
2.16.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ