linux.git/drivers/pci/hotplug, 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

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

PCI: hotplug: Don't leak pci_slot on registration failure

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

commit 4ce6435820d1f1cc2c2788e232735eb244bcc8a3 upstream.

If addition of sysfs files fails on registration of a hotplug slot, the
struct pci_slot as well as the entry in the slot_list is leaked.  The
issue has been present since the hotplug core was introduced in 2002:
https://git.kernel.org/tglx/history/c/a8a2069f432c

Perhaps the idea was that even though sysfs addition fails, the slot
should still be usable.  But that's not how drivers use the interface,
they abort probe if a non-zero value is returned.

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

PCI: Fix is_added/is_busmaster race condition

2018-07-31T16:27:54+00:00

When a PCI device is detected, pdev->is_added is set to 1 and proc and
sysfs entries are created.

When the device is removed, pdev->is_added is checked for one and then
device is detached with clearing of proc and sys entries and at end,
pdev->is_added is set to 0.

is_added and is_busmaster are bit fields in pci_dev structure sharing same
memory location.

A strange issue was observed with multiple removal and rescan of a PCIe
NVMe device using sysfs commands where is_added flag was observed as zero
instead of one while removing device and proc,sys entries are not cleared.
This causes issue in later device addition with warning message
"proc_dir_entry" already registered.

Debugging revealed a race condition between the PCI core setting the
is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue
setting the is_busmaster bit in pci_set_master().  As these fields are not
handled atomically, that clears the is_added bit.

Move the is_added bit to a separate private flag variable and use atomic
functions to set and retrieve the device addition state.  This avoids the
race because is_added no longer shares a memory location with is_busmaster.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283
Signed-off-by: Hari Vyas 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner 
Acked-by: Michael Ellerman

PCI: shpchp: Manage SHPC unconditionally on non-ACPI systems

2018-06-26T13:22:45+00:00

An SHPC can be operated either by platform firmware or by the OS.  The OS
uses a host bridge ACPI _OSC method to negotiate for control of SHPC.  If
firmware wants to prevent an OS from operating an SHPC, it must supply an
_OSC method that declines to grant SHPC ownership to the OS.

If acpi_pci_find_root() returns NULL, it means there's no ACPI host bridge
device (PNP0A03 or PNP0A08) and hence no _OSC method, so the OS is always
allowed to manage the SHPC.

Fix a NULL pointer dereference when CONFIG_ACPI=y but the current
hardware/firmware platform doesn't support ACPI.  In that case,
acpi_get_hp_hw_control_from_firmware() is implemented but
acpi_pci_find_root() returns NULL.

Fixes: 90cc0c3cc709 ("PCI: shpchp: Add shpchp_is_native()")
Link: https://lkml.kernel.org/r/20180621164715.28160-1-marc.zyngier@arm.com
Reported-by: Marc Zyngier 
Tested-by: Marc Zyngier 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Mika Westerberg

Merge branch 'pci/hotplug'

2018-06-06T21:10:10+00:00

  - fix use-before-set error in ibmphp (Dan Carpenter)

  - fix pciehp timeouts caused by Command Completed errata (Bjorn Helgaas)

  - fix refcounting in pnv_php hotplug (Julia Lawall)

  - clear pciehp Presence Detect and Data Link Layer Status Changed on
    resume so we don't miss hotplug events (Mika Westerberg)

  - only request pciehp control if we support it, so platform can use ACPI
    hotplug otherwise (Mika Westerberg)

  - convert SHPC to be builtin only (Mika Westerberg)

  - request SHPC control via _OSC if we support it (Mika Westerberg)

  - simplify SHPC handoff from firmware (Mika Westerberg)

* pci/hotplug:
  PCI: Improve "partially hidden behind bridge" log message
  PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() doc
  PCI: Move resource distribution for single bridge outside loop
  PCI: Account for all bridges on bus when distributing bus numbers
  ACPI / hotplug / PCI: Drop unnecessary parentheses
  ACPI / hotplug / PCI: Mark stale PCI devices disconnected
  ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug
  PCI: hotplug: Add hotplug_is_native()
  PCI: shpchp: Add shpchp_is_native()
  PCI: shpchp: Fix AMD POGO identification
  PCI: shpchp: Use dev_printk() for OSHP-related messages
  PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapper
  PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flags
  PCI: shpchp: Rely on previous _OSC results
  PCI: shpchp: Request SHPC control via _OSC when adding host bridge
  PCI: shpchp: Convert SHPC to be builtin only
  PCI: pciehp: Make pciehp_is_native() stricter
  PCI: pciehp: Rename host->native_hotplug to host->native_pcie_hotplug
  PCI: pciehp: Request control of native hotplug only if supported
  PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume
  PCI: pnv_php: Add missing of_node_put()
  PCI: pciehp: Add quirk for Command Completed errata
  PCI: Add Qualcomm vendor ID
  PCI: ibmphp: Fix use-before-set in get_max_bus_speed()

# Conflicts:
#	drivers/acpi/pci_root.c

ACPI / hotplug / PCI: Drop unnecessary parentheses

2018-06-04T17:08:06+00:00

Remove unnecessary parentheses.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Mark stale PCI devices disconnected

2018-06-04T17:08:06+00:00

Following PCIehp mark the unplugged PCI devices disconnected.  This makes
sure PCI core code leaves the now missing hardware registers alone.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko

ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug

2018-06-04T17:08:06+00:00

When acpiphp re-enumerates a PCI hierarchy because of an ACPI Notify()
event, we should skip bridges managed by native hotplug (pciehp or shpchp).
We don't want to scan below a native hotplug bridge until the hotplug
controller generates a hot-add event.

A typical scenario is a Root Port leading to a Thunderbolt host router that
remains powered off until something is connected to it.  See [1] for the
lspci details.

  1. Before something is connected, only the Root Port exists.  It has
     PCI_EXP_SLTCAP_HPC set and pciehp is responsible for hotplug:

       00:1b.0 Root Port (HotPlug+)

  2. When a USB-C or Thunderbolt device is connected, the Switch in the
     Thunderbolt host router is powered up, the Root Port signals a hotplug
     add event and pciehp enumerates the Switch:

       01:00.0 Switch Upstream Port   to [bus 02-39]
       02:00.0 Switch Downstream Port to [bus 03]    (HotPlug-, to NHI)
       02:01.0 Switch Downstream Port to [bus 04-38] (HotPlug+, to Thunderbolt connector)
       02:02.0 Switch Downstream Port to [bus 39]    (HotPlug-, to xHCI)

     The 02:00.0 and 02:02.0 Ports lead to Endpoints that are not powered
     up yet.  The Ports have PCI_EXP_SLTCAP_HPC cleared, so pciehp doesn't
     handle hotplug for them and we assign minimal resources to them.

     The 02:01.0 Port has PCI_EXP_SLTCAP_HPC set, so pciehp handles native
     hotplug events for it.

  3. The BIOS powers up the xHCI controller.  If a Thunderbolt device was
     connected (not just a USB-C device), it also powers up the NHI.  Then
     it sends an ACPI Notify() to the Root Port, and acpiphp enumerates the
     new device(s):

       03:00.0 Thunderbolt Host Controller (NHI) Endpoint
       39:00.0 xHCI Endpoint

  4. If a Thunderbolt device was connected, the host router firmware uses
     the NHI to set up Thunderbolt tunnels and triggers a native hotplug
     event (via 02:01.0 in this example).  Then pciehp enumerates the new
     Thunderbolt devices:

       04:00.0 Switch Upstream Port   to [bus 05-38]
       05:01.0 Switch Downstream Port to [bus 06-09] (HotPlug-)
       05:04.0 Switch Downstream Port to [bus 0a-38] (HotPlug+)

     In this example, 05:01.0 leads to another Switch and some NICs.  This
     subtree is static, so 05:01.0 doesn't support hotplug and has
     PCI_EXP_SLTCAP_HPC cleared.

In step 3, acpiphp previously enumerated everything below the Root Port,
including things below the 02:01.0 Port.  We don't want that because pciehp
expects to manage hotplug below that Port, and firmware on the host router
may be in the middle of configuring its Link so it may not be ready yet.

To make this work better with the native PCIe (pciehp) and standard PCI
(shpchp) hotplug drivers, we let them handle all slot management and
resource allocation for hotplug bridges and restrict ACPI hotplug to
non-hotplug bridges.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=199581#c5
Link: https://lkml.kernel.org/r/20180529160155.1738-1-mika.westerberg@linux.intel.com
Signed-off-by: Mika Westerberg 
[bhelgaas: changelog, use hotplug_is_native() instead of
dev->is_hotplug_bridge]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko