kernel.git/drivers/pci/pcie, branch linux-4.5.y

PCI/AER: Flush workqueue on device remove to avoid use-after-free

2016-01-25T16:08:00Z

A Root Port's AER structure (rpc) contains a queue of events. aer_irq() enqueues AER status information and schedules aer_isr() to dequeue and process it. When we remove a device, aer_remove() waits for the queue to be empty, then frees the rpc struct. But aer_isr() references the rpc struct after dequeueing and possibly emptying the queue, which can cause a use-after-free error as in the following scenario with two threads, aer_isr() on the left and a concurrent aer_remove() on the right: Thread A Thread B -------- -------- aer_irq(): rpc->prod_idx++ aer_remove(): wait_event(rpc->prod_idx == rpc->cons_idx) # now blocked until queue becomes empty aer_isr(): # ... rpc->cons_idx++ # unblocked because queue is now empty ... kfree(rpc) mutex_unlock(&rpc->rpc_mutex) To prevent this problem, use flush_work() to wait until the last scheduled instance of aer_isr() has completed before freeing the rpc struct in aer_remove(). I reproduced this use-after-free by flashing a device FPGA and re-enumerating the bus to find the new device. With SLUB debug, this crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in GPR25: pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000 Unable to handle kernel paging request for data at address 0x27ef9e3e Workqueue: events aer_isr GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0 NIP [602f5328] pci_walk_bus+0xd4/0x104 [bhelgaas: changelog, stable tag] Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org

Merge branch 'pci/host-vmd' into next

2016-01-15T22:14:39Z

* pci/host-vmd: x86/PCI: Add driver for Intel Volume Management Device (VMD) PCI/AER: Use 32 bit PCI domain numbers x86/PCI: Allow DMA ops specific to a PCI domain irqdomain: Export irq_domain_set_info() for module use genirq/MSI: Relax msi_domain_alloc() to support parentless MSI irqdomains

PCI/AER: Use 32 bit PCI domain numbers

2016-01-15T19:54:55Z

The Intel Volume Management Device (VMD) supports 32-bit domain numbers. To accommodate this, use u32 instead of u16 to store domain numbers. [bhelgaas: changelog] Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas

Merge branches 'pci/aspm', 'pci/hotplug', 'pci/misc' and 'pci/msi' into next

2015-12-11T01:40:14Z

* pci/aspm: PCI/ASPM: Make sysfs link_state_store() consistent with link_state_show() * pci/hotplug: PCI: pciehp: Always protect pciehp_disable_slot() with hotplug mutex * pci/misc: x86/PCI: Simplify pci_bios_{read,write} PCI: Simplify config space size computation PCI: Limit config space size for Netronome NFP6000 family PCI: Add Netronome vendor and device IDs PCI: Support PCIe devices with short cfg_size x86/PCI: Clarify AMD Fam10h config access restrictions comment PCI: Print warnings for all invalid expansion ROM headers PCI: Check for PCI_HEADER_TYPE_BRIDGE equality, not bitmask * pci/msi: PCI/MSI: Remove empty pci_msi_init_pci_dev() PCI/MSI: Initialize MSI capability for all architectures

PCI: Check for PCI_HEADER_TYPE_BRIDGE equality, not bitmask

2015-12-11T01:38:06Z

Bit 7 of the "Header Type" register indicates a multi-function device when set. Bits 0-6 contain encoded values, where 0x1 indicates a PCI-PCI bridge. It is incorrect to test this as though it were a mask. For example, while the PCI 3.0 spec only defines values 0x0, 0x1, and 0x2, it's conceivable that a future spec could define 0x3 to mean something else; then tests for "(hdr_type & 0x7f) & PCI_HEADER_TYPE_BRIDGE" would incorrectly succeed for this new 0x3 header type. Test bits 0-6 of the Header Type for equality with PCI_HEADER_TYPE_BRIDGE. Signed-off-by: Bjorn Helgaas

PCI/ASPM: Make sysfs link_state_store() consistent with link_state_show()

2015-12-03T16:42:59Z

If CONFIG_PCIEASPM_DEBUG is set, then PCI devices have a link_state attribute. Reading that attribute shows the state as a bit mask: 1 means L0S upstream, 2 means L0S downstream, and 4 means L1. Oddly, writing to link_state is inconsistent and gets translated, leading to mysterious results in which the value you store isn't comparable the value you load back out. Fix it by making link_state_store() match link_state_show(). [bhelgaas: Check "aspm_disabled" *before* validating input. When "aspm_disabled" is set, this changes the error for invalid input from -EINVAL to -EPERM.] Signed-off-by: Andy Lutomirski Signed-off-by: Bjorn Helgaas

PCI/AER: Clear error status registers during enumeration and restore

2015-09-17T15:09:37Z

AER errors might be recorded when powering-on devices. These errors can be ignored, so firmware usually clears them before the OS enumerates devices. However, firmware is not involved when devices are added via hotplug, so the OS may discover power-up errors that should be ignored. The same may happen when powering up devices when resuming after suspend. Clear the AER error status registers during enumeration and resume. [bhelgaas: changelog, remove repetitive comments] Signed-off-by: Taku Izumi Signed-off-by: Bjorn Helgaas

PCI: Fix pcie_port_device_resume() comment

2015-07-14T18:41:04Z

The function comment claimed this was pcie_port_device_suspend(), but it's really pcie_port_device_resume(). Perils of cut and paste. Use the correct function name in the comment. Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki

PCI/ASPM: Simplify Clock Power Management setting

2015-06-10T19:00:21Z

Update the Link Control Enable Clock Power Management bit the same way we update the ASPM Control bits, with a single call of pcie_capability_clear_and_set_word(). No functional change; this just makes both paths use the same style. Signed-off-by: Bjorn Helgaas

PCI: Use dev->has_secondary_link to find downstream PCIe links

2015-05-29T20:35:26Z

Previously we assumed that PCIe Root Ports and Downstream Ports had Links on their secondary side. That is true in most systems, but it is possible to connect a switch with either an Upstream or a Downstream Port leading downstream. Instead of relying on the component type to identify devices that have links leading downstream, use the "dev->has_secondary_link" field. [bhelgaas: changelog] Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas