From: Abhin Parekadan Jose <abhinjoses@gmail.com>
To: lukas@wunner.de, mst@redhat.com
Cc: virtualization@lists.linux.dev, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
kbusch@kernel.org, stefanha@redhat.com, parav@nvidia.com,
axboe@kernel.dk, kees@kernel.org, ilpo.jarvinen@linux.intel.com,
xueshuai@linux.alibaba.com,
Abhin Parekadan Jose <abhinjoses@gmail.com>
Subject: [PATCH RFC 0/3] pci_hp: fix surprise removal hang during safe removal
Date: Sun, 23 Aug 2026 18:34:52 +0000 [thread overview]
Message-ID: <20260823183458.982699-1-abhinjoses@gmail.com> (raw)
In-Reply-To: <cover.1752094439.git.mst@redhat.com>
This series is based on top of MST's RFC v5
(cover.1752094439.git.mst@redhat.com) and tries to address the architectural
gap identified by Lukas Wunner in that thread.
Context:
MST's RFC v5 adds disconnect_work infrastructure so drivers can be
notified of surprise removal. Lukas identified a race that the
series cannot address: if safe removal is already in progress when the
device is yanked, pciehp_ist() is blocked and cannot deliver the
disconnect event.
Potential fix:
I reproduced this with a simple edu device driver (patch 1) that blocks
in remove() waiting for an interrupt. Same as blk_mq_freeze_queue_wait().
deadlock in pciehp_ist() is avoided by adding a workaround in pciehp_isr() (patch 3)
where a disconnect_work is scheduled and as this is a different thread it runs and
dispatches the disconnect event to the driver. The driver can then unblock and complete
the remove() and thus breaking the deadlock and also overcoming the problem of
not waiting in pciehp_isr().This is only schduled if the PDS is set to 0
indicating that there is no card attached at this slot in pciehp_isr().
Tested using qemu:
- Hacked the edu device to raise a delayed interrupt.
- Hacked qemu to actually act like suprise removal by adding a simple monitor cmd
`pcie_surprise_del` to remove the device and genrate PDC=1, DLLSC = 1 and PDS=0.
1. Launched qemu with the edu device:
`-device pcie-root-port,id=rp1,chassis=1,slot=1 -device edu,bus=rp1,id=edu0`
2. Ran `echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove` to start safe removal
3. Ran `pcie_surprise_del edu0` to surprise remove the device while safe removal
is in progress.
4. Verified that `edu_remove()` and `edu_disconnect()` are called.
Without the fix: remove() hangs permanently.
With the fix: pciehp_isr() fires, pciehp_disconnect_work() schedules
pci_dev_set_disconnected(), edu_disconnect() completes the wait, remove()
proceeds.
Would this be a viable approach?
Assisted-by: Claude:claude-sonnet-4-6
Abhin Parekadan Jose (3):
misc: add edu_srpoc surprise removal POC driver
pciehp: add disconnect_work work_struct
pciehp_hpc: workaround to not wait in pciehp_isr on surprise removal
drivers/misc/Makefile | 1 +
drivers/misc/edu_srpoc.c | 180 +++++++++++++++++++++++++++++++
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 47 ++++++++
4 files changed, 229 insertions(+)
create mode 100644 drivers/misc/edu_srpoc.c
--
2.51.1
next prev parent reply other threads:[~2026-08-23 18:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1752094439.git.mst@redhat.com>
2025-07-09 20:55 ` [PATCH RFC v5 1/5] pci: report surprise removal event Michael S. Tsirkin
2025-07-09 23:38 ` Bjorn Helgaas
2025-07-09 23:55 ` Keith Busch
2025-07-14 6:17 ` Michael S. Tsirkin
2025-07-14 6:26 ` Michael S. Tsirkin
2025-07-14 21:13 ` Bjorn Helgaas
2025-07-15 6:28 ` Michael S. Tsirkin
2025-07-16 22:29 ` Bjorn Helgaas
2025-07-17 15:15 ` Michael S. Tsirkin
2025-07-14 6:11 ` Lukas Wunner
2025-07-14 6:18 ` Michael S. Tsirkin
2025-07-14 6:54 ` Michael S. Tsirkin
2025-07-17 15:11 ` Michael S. Tsirkin
2025-07-17 20:12 ` Lukas Wunner
2025-07-17 23:31 ` Michael S. Tsirkin
2025-07-18 4:35 ` Lukas Wunner
2025-07-18 8:40 ` Michael S. Tsirkin
2026-08-23 18:34 ` Abhin Parekadan Jose [this message]
2026-08-23 18:34 ` [PATCH RFC 1/3] misc: add edu_srpoc surprise removal POC driver Abhin Parekadan Jose
2026-08-23 18:44 ` sashiko-bot
2026-08-23 18:34 ` [PATCH RFC 2/3] pciehp: add disconnect_work work_struct Abhin Parekadan Jose
2026-08-23 18:44 ` sashiko-bot
2026-08-23 18:34 ` [PATCH RFC 3/3] pciehp_hpc: workaround to not wait in pciehp_isr on surprise removal Abhin Parekadan Jose
2026-08-23 18:44 ` sashiko-bot
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=20260823183458.982699-1-abhinjoses@gmail.com \
--to=abhinjoses@gmail.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kbusch@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xueshuai@linux.alibaba.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