linux.git/drivers/pci, branch v4.18.12

ACPI / hotplug / PCI: Don't scan for non-hotplug bridges if slot is not bridge

2018-10-03T23:59:20+00:00

commit f188b99f0b2d33794b4af8a225f95d1e968c0a3f upstream.

HP 6730b laptop has an ethernet NIC connected to one of the PCIe root
ports. The root ports themselves are native PCIe hotplug capable. Now,
during boot after PCI devices are scanned the BIOS triggers ACPI bus check
directly to the NIC:

ACPI: \_SB_.PCI0.RP06.NIC_: Bus check in hotplug_event()

It is not clear why it is sending bus check but regardless the ACPI hotplug
notify handler calls enable_slot() directly (instead of going through
acpiphp_check_bridge() as there is no bridge), which ends up handling
special case for non-hotplug bridges with native PCIe hotplug. This
results a crash of some kind but the reporter only sees black screen so it
is hard to figure out the exact spot and what actually happens. Based on
a few fix proposals it was tracked to crash somewhere inside
pci_assign_unassigned_bridge_resources().

In any case we should not really be in that special branch at all because
the ACPI notify happened to a slot that is not a PCI bridge (it is just a
regular PCI device).

Fix this so that we only go to that special branch if we are calling
enable_slot() for a bridge (e.g., the ACPI notification was for the
bridge).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201127
Fixes: 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug")
Reported-by: Peter Anemone
Signed-off-by: Mika Westerberg
Signed-off-by: Bjorn Helgaas
Reviewed-by: Rafael J. Wysocki
CC: stable@vger.kernel.org # v4.18+
Signed-off-by: Greg Kroah-Hartman

Revert "PCI: Add ACS quirk for Intel 300 series"

2018-09-29T09:55:57+00:00

commit 50ca031b51106b1b46162d4e9ecccb7edc95682f upstream.

This reverts f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series").

It turns out that erratum "PCH PCIe* Controller Root Port (ACSCTLR) Appear
As Read Only" has been fixed in 300 series chipsets, even though the
datasheet [1] claims otherwise.  To make ACS work properly on 300 series
root ports, revert the faulty commit.

[1] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/300-series-c240-series-chipset-pch-spec-update.pdf

Fixes: f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series")
Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Cc: stable@vger.kernel.org	# v4.18+
Signed-off-by: Greg Kroah-Hartman

PCI/AER: Honor "pcie_ports=native" even if HEST sets FIRMWARE_FIRST

2018-09-26T06:39:29+00:00

[ Upstream commit 7af02fcd84c16801958936f88b848944c726ca07 ]

According to the documentation, "pcie_ports=native", linux should use
native AER and DPC services.  While that is true for the _OSC method
parsing, this is not the only place that is checked.  Should the HEST
list PCIe ports as firmware-first, linux will not use native services.

This happens because aer_acpi_firmware_first() doesn't take 'pcie_ports'
into account.  This is wrong.  DPC uses the same logic when it decides
whether to load or not, so fixing this also fixes DPC not loading.

Signed-off-by: Alexandru Gagniuc 
[bhelgaas: return "false" from bool function (from kbuild robot)]
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: mobiveil: Fix struct mobiveil_pcie.pcie_reg_base address type

2018-09-19T20:41:33+00:00

[ Upstream commit af3f606e0bbb6d811c50b7b90fe324b07fb7cab8 ]

The field pcie_reg_base in struct mobiveil_pcie represents a physical
address so it should be of phys_addr_t type rather than void __iomem*;
this results in the following compilation  warnings:

drivers/pci/controller/pcie-mobiveil.c: In function
'mobiveil_pcie_parse_dt':
drivers/pci/controller/pcie-mobiveil.c:326:22: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
  pcie->pcie_reg_base = res->start;
                      ^
drivers/pci/controller/pcie-mobiveil.c: In function
'mobiveil_pcie_enable_msi':
drivers/pci/controller/pcie-mobiveil.c:485:25: warning: initialization
makes integer from pointer without a cast [-Wint-conversion]
  phys_addr_t msg_addr = pcie->pcie_reg_base;
                         ^~~~
drivers/pci/controller/pcie-mobiveil.c: In function
'mobiveil_compose_msi_msg':
drivers/pci/controller/pcie-mobiveil.c:640:21: warning: initialization
makes integer from pointer without a cast [-Wint-conversion]
  phys_addr_t addr = pcie->pcie_reg_base + (data->hwirq * sizeof(int));

Fix the type and with it the compilation warnings.

Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
driver")
Signed-off-by: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Subrahmanya Lingappa 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: mobiveil: Add missing ../pci.h include

2018-09-19T20:41:32+00:00

[ Upstream commit d3743012230f8dab30d47caba1f2ee9e382385e7 ]

PCI mobiveil host controller driver currently fails to compile
with the following error:

drivers/pci/controller/pcie-mobiveil.c: In function
'mobiveil_pcie_probe':
drivers/pci/controller/pcie-mobiveil.c:788:8: error: implicit
declaration of function 'devm_of_pci_get_host_bridge_resources'; did you
mean 'pci_get_host_bridge_device'?
[-Werror=implicit-function-declaration]
  ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        pci_get_host_bridge_device

Add the missing include file to pull in the required function declaration.

Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
driver")
Signed-off-by: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Subrahmanya Lingappa 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

switchtec: Fix Spectre v1 vulnerability

2018-09-19T20:41:23+00:00

commit 46feb6b495f7628a6dbf36c4e6d80faf378372d4 upstream.

p.port can is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

  drivers/pci/switch/switchtec.c:912 ioctl_port_to_pff() warn: potential spectre issue 'pcfg->dsp_pff_inst_id' [r]

Fix this by sanitizing p.port before using it to index
pcfg->dsp_pff_inst_id

Notice that given that speculation windows are large, the policy is to kill
the speculation on the first load and not worry if it can be completed with
a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Bjorn Helgaas 
Acked-by: Logan Gunthorpe 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: mvebu: Fix I/O space end address calculation

2018-09-15T07:46:52+00:00

[ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ]

pcie->realio.end should be the address of last byte of the area,
therefore using resource_size() of another resource is not correct, we
must substract 1 to get the address of the last byte.

Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Match Root Port's MPS to endpoint's MPSS as necessary

2018-09-15T07:46:50+00:00

[ Upstream commit 9f0e89359775ee21fe1ea732e34edb52aef5addf ]

In commit 27d868b5e6cf ("PCI: Set MPS to match upstream bridge"), we made
sure every device's MPS setting matches its upstream bridge, making it more
likely that a hot-added device will work in a system with an optimized MPS
configuration.

Recently I've started encountering systems where the endpoint device's MPSS
capability is less than its Root Port's current MPS value, thus the
endpoint is not capable of matching its upstream bridge's MPS setting (see:
bugzilla via "Link:" below).  This leaves the system vulnerable - the
upstream Root Port could respond with larger TLPs than the device can
handle, and the device will consider them to be 'Malformed'.

One could use the "pci=pcie_bus_safe" kernel parameter to work around the
issue, but that forces a user to supply a kernel parameter to get the
system to function reliably and may end up limiting MPS settings of other
unrelated, sub-topologies which could benefit from maintaining their larger
values.

Augment Keith's approach to include tuning down a Root Port's MPS setting
when its hot-added endpoint device is not capable of matching it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jon Mason 
Cc: Keith Busch 
Cc: Sinan Kaya 
Cc: Dongdong Liu 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Fix unprotected list iteration in IRQ handler

2018-08-24T11:04:51+00:00

commit 1204e35bedf4e5015cda559ed8c84789a6dae24e upstream.

Commit b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
events for a device") iterates over the devices on a hotplug port's
subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
It is thus possible for a user to cause a crash by concurrently
manipulating the device list, e.g. by disabling slot power via sysfs
on a different CPU or by initiating a remove/rescan via sysfs.

This can't be fixed by acquiring pci_bus_sem because it may sleep.
The simplest fix is to avoid the list iteration altogether and just
check the ignore_hotplug flag on the port itself.  This works because
pci_ignore_hotplug() sets the flag both on the device as well as on its
parent bridge.

We do lose the ability to print the name of the device blocking hotplug
in the debug message, but that's probably bearable.

Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Signed-off-by: Lukas Wunner 
Signed-off-by: Bjorn Helgaas 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Fix use-after-free on unplug

2018-08-24T11:04:51+00:00

commit 281e878eab191cce4259abbbf1a0322e3adae02c upstream.

When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
hotplug_slot struct is deregistered and thus freed before freeing the
IRQ.  The IRQ handler and the work items it schedules print the slot
name referenced from the freed structure in various informational and
debug log messages, each time resulting in a quadruple dereference of
freed pointers (hotplug_slot -> pci_slot -> kobject -> name).

At best the slot name is logged as "(null)", at worst kernel memory is
exposed in logs or the driver crashes:

  pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present

An attacker may provoke the bug by unplugging multiple devices on a
Thunderbolt daisy chain at once.  Unplugging can also be simulated by
powering down slots via sysfs.  The bug is particularly easy to trigger
in poll mode.

It has been present since the driver's introduction in 2004:
https://git.kernel.org/tglx/history/c/c16b4b14d980

Fix by rearranging teardown such that the IRQ is freed first.  Run the
work items queued by the IRQ handler to completion before freeing the
hotplug_slot struct by draining the work queue from the ->release_slot
callback which is invoked by pci_hp_deregister().

Signed-off-by: Lukas Wunner 
Signed-off-by: Bjorn Helgaas 
Cc: stable@vger.kernel.org # v2.6.4
Signed-off-by: Greg Kroah-Hartman