public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Dongli Zhang <dongli.zhang@oracle.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	imammedo@redhat.com, mst@redhat.com, rafael@kernel.org,
	lenb@kernel.org, bhelgaas@google.com,
	mika.westerberg@linux.intel.com, boris.ostrovsky@oracle.com,
	joe.jin@oracle.com, stable@vger.kernel.org,
	Fiona Ebner <f.ebner@proxmox.com>,
	Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: [RFC 1/2] PCI: acpiphp: enable slot only if it hasn't been enabled already
Date: Wed, 13 Dec 2023 01:36:13 +0100	[thread overview]
Message-ID: <20231213003614.1648343-2-imammedo@redhat.com> (raw)
In-Reply-To: <20231213003614.1648343-1-imammedo@redhat.com>

When SCSI_SCAN_ASYNC is enabled (either via config or via cmd line),
adding device to bus and enabling it will kick in async host scan

 scsi_scan_host+0x21/0x1f0
 virtscsi_probe+0x2dd/0x350
 ..
 driver_probe_device+0x19/0x80
 ...
 driver_probe_device+0x19/0x80
 pci_bus_add_device+0x53/0x80
 pci_bus_add_devices+0x2b/0x70
 ...

which will schedule a job for async scan. That however breaks
if there are more than one SCSI host behind bridge, since
acpiphp_check_bridge() will walk over all slots and try to
enable each of them regardless of whether they were already
enabled.
As result the bridge might be reconfigured several times
and trigger following sequence:

  [cpu 0] acpiphp_check_bridge()
  [cpu 0]   enable_slot(a)
  [cpu 0]     configure bridge
  [cpu 0]     pci_bus_add_devices() -> scsi_scan_host(a1)
  [cpu 0]   enable_slot(b)
  ...
  [cpu 1] do_scsi_scan_host(a1) <- async jib scheduled for slot a
  ...
  [cpu 0]     configure bridge <- temporaly disables bridge

and cause do_scsi_scan_host() failure.
The same race affects SHPC (but it manages to avoid hitting the race due to
1sec delay when enabling slot).
To cover case of single device hotplug (at a time) do not attempt to
enable slot that have already been enabled.

Fixes: 40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
Reported-by: iona Ebner <f.ebner@proxmox.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
 drivers/pci/hotplug/acpiphp_glue.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index 601129772b2d..6b11609927d6 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -722,7 +722,9 @@ static void acpiphp_check_bridge(struct acpiphp_bridge *bridge)
 					trim_stale_devices(dev);
 
 			/* configure all functions */
-			enable_slot(slot, true);
+			if (slot->flags != SLOT_ENABLED) {
+				enable_slot(slot, true);
+			}
 		} else {
 			disable_slot(slot);
 		}
-- 
2.39.3


  reply	other threads:[~2023-12-13  0:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  0:36 [RFC 0/2] PCI: acpiphp: workaround race between hotplug and SCSI_SCAN_ASYNC job Igor Mammedov
2023-12-13  0:36 ` Igor Mammedov [this message]
2023-12-13  9:47   ` [RFC 1/2] PCI: acpiphp: enable slot only if it hasn't been enabled already Fiona Ebner
2023-12-13 10:07     ` Igor Mammedov
2023-12-13 13:01   ` Rafael J. Wysocki
2023-12-13 16:06     ` Igor Mammedov
2023-12-13  0:36 ` [RFC 2/2] PCI: acpiphp: slowdown hotplug if hotplugging multiple devices at a time Igor Mammedov
2023-12-13  7:26   ` Greg KH
2023-12-13  8:13   ` Dongli Zhang
2023-12-13 10:05     ` Igor Mammedov
2023-12-13 17:25       ` Dongli Zhang
2023-12-13  9:47   ` Fiona Ebner
2023-12-13 13:07   ` Rafael J. Wysocki
2023-12-13 16:49     ` Igor Mammedov
2023-12-13 16:54       ` Michael S. Tsirkin
2023-12-13 17:09         ` Dongli Zhang
2024-01-03  9:54           ` Igor Mammedov
2024-01-03 16:19             ` Dongli Zhang
2023-12-13 18:50         ` Igor Mammedov
2023-12-13  8:12 ` [RFC 0/2] PCI: acpiphp: workaround race between hotplug and SCSI_SCAN_ASYNC job Dongli Zhang
2023-12-13 18:11 ` Bjorn Helgaas
2023-12-13 18:12   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231213003614.1648343-2-imammedo@redhat.com \
    --to=imammedo@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dongli.zhang@oracle.com \
    --cc=f.ebner@proxmox.com \
    --cc=joe.jin@oracle.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mst@redhat.com \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox