From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: "Jiwei Sun" <sunjw10@lenovo.com>,
"Adrian Huang" <ahuang12@lenovo.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Nirmal Patel" <nirmal.patel@linux.intel.com>,
"Sasha Levin" <sashal@kernel.org>,
lpieralisi@kernel.org, kw@linux.com, linux-pci@vger.kernel.org
Subject: [PATCH AUTOSEL 5.15 11/13] PCI: vmd: Create domain symlink before pci_bus_add_devices()
Date: Sun, 28 Jul 2024 12:08:53 -0400 [thread overview]
Message-ID: <20240728160907.2053634-11-sashal@kernel.org> (raw)
In-Reply-To: <20240728160907.2053634-1-sashal@kernel.org>
From: Jiwei Sun <sunjw10@lenovo.com>
[ Upstream commit f24c9bfcd423e2b2bb0d198456412f614ec2030a ]
The vmd driver creates a "domain" symlink in sysfs for each VMD bridge.
Previously this symlink was created after pci_bus_add_devices() added
devices below the VMD bridge and emitted udev events to announce them to
userspace.
This led to a race between userspace consumers of the udev events and the
kernel creation of the symlink. One such consumer is mdadm, which
assembles block devices into a RAID array, and for devices below a VMD
bridge, mdadm depends on the "domain" symlink.
If mdadm loses the race, it may be unable to assemble a RAID array, which
may cause a boot failure or other issues, with complaints like this:
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: Unable to get real path for '/sys/bus/pci/drivers/vmd/0000:c7:00.5/domain/device''
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: /dev/nvme1n1 is not attached to Intel(R) RAID controller.'
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: No OROM/EFI properties for /dev/nvme1n1'
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: no RAID superblock on /dev/nvme1n1.'
(udev-worker)[2149]: nvme1n1: Process '/sbin/mdadm -I /dev/nvme1n1' failed with exit code 1.
This symptom prevents the OS from booting successfully.
After a NVMe disk is probed/added by the nvme driver, udevd invokes mdadm
to detect if there is a mdraid associated with this NVMe disk, and mdadm
determines if a NVMe device is connected to a particular VMD domain by
checking the "domain" symlink. For example:
Thread A Thread B Thread mdadm
vmd_enable_domain
pci_bus_add_devices
__driver_probe_device
...
work_on_cpu
schedule_work_on
: wakeup Thread B
nvme_probe
: wakeup scan_work
to scan nvme disk
and add nvme disk
then wakeup udevd
: udevd executes
mdadm command
flush_work main
: wait for nvme_probe done ...
__driver_probe_device find_driver_devices
: probe next nvme device : 1) Detect domain symlink
... 2) Find domain symlink
... from vmd sysfs
... 3) Domain symlink not
... created yet; failed
sysfs_create_link
: create domain symlink
Create the VMD "domain" symlink before invoking pci_bus_add_devices() to
avoid this race.
Suggested-by: Adrian Huang <ahuang12@lenovo.com>
Link: https://lore.kernel.org/linux-pci/20240605124844.24293-1-sjiwei@163.com
Signed-off-by: Jiwei Sun <sunjw10@lenovo.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Nirmal Patel <nirmal.patel@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/controller/vmd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index f49001ba96c75..10a078ef4799d 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -798,6 +798,9 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
if (vmd->irq_domain)
dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain);
+ WARN(sysfs_create_link(&vmd->dev->dev.kobj, &vmd->bus->dev.kobj,
+ "domain"), "Can't create symlink to domain\n");
+
vmd_acpi_begin();
pci_scan_child_bus(vmd->bus);
@@ -814,9 +817,6 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
pci_bus_add_devices(vmd->bus);
vmd_acpi_end();
-
- WARN(sysfs_create_link(&vmd->dev->dev.kobj, &vmd->bus->dev.kobj,
- "domain"), "Can't create symlink to domain\n");
return 0;
}
@@ -873,8 +873,8 @@ static void vmd_remove(struct pci_dev *dev)
{
struct vmd_dev *vmd = pci_get_drvdata(dev);
- sysfs_remove_link(&vmd->dev->dev.kobj, "domain");
pci_stop_root_bus(vmd->bus);
+ sysfs_remove_link(&vmd->dev->dev.kobj, "domain");
pci_remove_root_bus(vmd->bus);
vmd_cleanup_srcu(vmd);
vmd_detach_resources(vmd);
--
2.43.0
next prev parent reply other threads:[~2024-07-28 16:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-28 16:08 [PATCH AUTOSEL 5.15 01/13] PCI: Add ACS quirk for Broadcom BCM5760X NIC Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 02/13] PCI: Use preserve_config in place of pci_flags Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 03/13] usb: cdns3: Add quirk flag to enable suspend residency Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 04/13] usb: dwc2: gadget: Don't write invalid mapped sg entries into dma_desc with iommu enabled Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 05/13] usb: typec: ucsi: Fix null pointer dereference in trace Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 06/13] MIPS: Loongson64: DTS: Fix msi node for ls7a Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 07/13] MIPS: Loongson64: DTS: Fix PCIe port nodes " Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 08/13] PCI/AER: Disable AER service on suspend Sasha Levin
2024-07-28 16:08 ` Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 09/13] ASoC: Intel: sof_sdw: fix jack detection on ADL-N variant RVP Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 10/13] PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Sasha Levin
2024-07-28 16:08 ` Sasha Levin [this message]
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 12/13] PCI: Add missing bridge lock to pci_bus_lock() Sasha Levin
2024-07-28 16:08 ` [PATCH AUTOSEL 5.15 13/13] ALSA: usb: Fix UBSAN warning in parse_audio_unit() Sasha Levin
2024-12-17 6:24 ` Harshit Mogalapalli
2024-12-17 19:15 ` Sasha Levin
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=20240728160907.2053634-11-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=ahuang12@lenovo.com \
--cc=bhelgaas@google.com \
--cc=kw@linux.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=nirmal.patel@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=sunjw10@lenovo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.