linux-kernel - [PATCH v4 3/3] PCI: pciehp: Clear AtomicOps unconditionally on hot remove.

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: <20230815212043.114913-4-Smita.KoralahalliChannabasappa@amd.com>
Date:   Tue, 15 Aug 2023 21:20:43 +0000
From:   Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
To:     <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
        Lukas Wunner <lukas@...ner.de>,
        "Kuppuswamy Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Subject: [PATCH v4 3/3] PCI: pciehp: Clear AtomicOps unconditionally on hot remove.

On a hot-plug, the optional capabilities ARI Forwarding Enable, AtomicOp
Requester Enable and 10-Bit Tag Requester Enable in DEVCTL2 must be
re-negotiated between endpoint and root port for optimal operation.

PCIe r6.0 sec 6.13 and 6.15 [1], points out that following a hot-plug
event, clear the ARI Forwarding Enable bit and AtomicOp Requester Enable
as its not determined whether the next device inserted will support these
capabilities. AtomicOp capabilities are not supported on PCI Express to
PCI/PCI-X Bridges and any newly added component may not be an ARI device.

The enablement and disablement of ARI Forwarding Enable and 10-bit Tag
Requester Enable is already been taken care in pci_configure_ari() and
pci_configure_ten_bit_tag() respectively.

AtomicOp requests are not enabled indiscriminately by PCI core as there
could be devices where AtomicOps are nominally supported but untested or
broken. Additionally, there is no explicit capability bit to determine
the support for AtomicOps Requester.

Moreover, it is difficult to determine if the AtomicOps are enabled by
reading the "AtomicOp Requester Enable" Device Control 2 register as
the PCIe r6.0 sec 7.5.3.16 [1], states "AtomicOps Requester Enable is
permitted to be RW even if no AtomicOp Requester capabilities are
supported by the Endpoint or Root Port", thereby substantiating devices
that hardwires this bit to '1' is also valid. Hence, clear AtomicOp
Requester Enable unconditionally on hot remove.

[1] PCI Express Base Specification Revision 6.0, Dec 16 2021.
    https://members.pcisig.com/wg/PCI-SIG/document/16609

Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
---
v2:
	Clear all optional capabilities in Device Control 2 register
	instead of individually clearing ARI Forwarding Enable,
	AtomicOp Requestor Enable and 10-bit Tag Requestor Enable.
v3:
	Restore clearing only ARI, Atomic Op and 10 bit tags as these are
	the optional capabilities.
	Provide all necessary information in commit description.
	Clear register bits of the hotplug port.
v4:
	Cleared only AtomicOps instead of all three bits.
	Removed brackets.
	Moved clearing at the end after pci_unlock_rescan_remove().
---
 drivers/pci/hotplug/pciehp_pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index ad12515a4a12..a3adbe89239c 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -134,4 +134,7 @@ void pciehp_unconfigure_device(struct controller *ctrl, bool presence)
 	}

 	pci_unlock_rescan_remove();
+
+	pcie_capability_clear_word(ctrl->pcie->port, PCI_EXP_DEVCTL2,
+				   PCI_EXP_DEVCTL2_ATOMIC_REQ);
 }
-- 
2.17.1