From: Abhin Parekadan Jose <abhinjoses@gmail.com>
To: bhelgaas@google.com, lukas@wunner.de, mst@redhat.com
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
ilpo.jarvinen@linux.intel.com, kees@kernel.org,
xueshuai@linux.alibaba.com,
Abhin Parekadan Jose <abhinjoses@gmail.com>
Subject: [PATCH RFC 0/3] PCI: pciehp: Report surprise removal during safe removal
Date: Sat, 5 Sep 2026 18:38:57 +0000 [thread overview]
Message-ID: <20260905183905.997833-1-abhinjoses@gmail.com> (raw)
Bjorn asked for this to be pulled out of the dormant virtio thread and
posted separately as a purely PCI series [1]. This is that repost. It
carries one patch from Michael's RFC v5 as a dependency and drops the
virtio side entirely.
The problem, as identified by Lukas [2]: if a safe removal is already in
progress when the device is surprise removed, pciehp cannot report the
disconnect. The removal blocks waiting on a device interrupt or status
read, and the IRQ thread is single-threaded and is itself executing that
removal, so it never runs again to report the device gone. The removal
hangs indefinitely.
Lukas noted that pciehp_isr() does run while the IRQ thread is blocked,
but argued this was not viable either, because pciehp_ist() must ignore
link and presence changes caused by SBR or DPC, and telling those apart
takes seconds which cannot be spent in hardirq.
Patch 2 sidesteps that by not doing the work in hardirq. pciehp_isr()
only checks PDS, and defers everything else to a work item running in
process context, where it is free to sleep and to repeat the spurious
link change test.
Patches:
1/3 Michael's "PCI: Report surprise removal event" from RFC v5,
unchanged apart from the fixing commit subject. Needed for
disconnect_work_enable and the disconnect_work.
2/3 The pciehp change. Adds disconnect_work to struct controller,
scheduled from pciehp_isr() on PDC or DLLSC when
!pciehp_card_present(). pciehp_disconnect_work() then runs in
process context, where it re-tests for spurious link changes and
confirms the card is still absent before scheduling the driver's
disconnect work.
3/3 A POC driver for the QEMU edu device that blocks in remove()
waiting for an interrupt, standing in for del_gendisk() stuck in
blk_mq_freeze_queue_wait(). Not for merge -- included so the
hang can be reproduced.
Testing
Reproducing this needs QEMU changes, since neither device_del nor the
attention button produces a true surprise removal. A branch with both
is here [3]:
- a delayed-IRQ register on the edu device (BAR0 0x30, write N ms)
- a pcie_surprise_del monitor command that drops the device and
generates PDC=1, DLLSC=1, PDS=0
Test 1 (Hang in remove() on the user thread, then suprise remove):
./qemu-system-aarch64 -machine virt,gic-version=3 -cpu cortex-a57 \
-m 512 -smp 2 -kernel Image -initrd initramfs.cpio.gz \
-device pcie-root-port,id=rp1,chassis=1,slot=1 \
-device edu,bus=rp1,id=edu0 -append "console=ttyAMA0 rdinit=/init" \
-nographic -monitor unix:/tmp/qemu-mon.sock,server,nowait
guest# echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
host$ echo "pcie_surprise_del edu0" | socat - unix-connect:/tmp/qemu-mon.sock
This is the test that MST had solved.
Test 2 (Hang in remove() on the IRQ thread, then suprise remove):
./qemu-system-aarch64 -machine virt,gic-version=3 -cpu cortex-a57 \
-m 512 -smp 2 -kernel Image -initrd initramfs.cpio.gz \
-device pcie-root-port,id=rp1,chassis=1,slot=1 \
-device edu,bus=rp1,id=edu0 -append "console=ttyAMA0 rdinit=/init" \
-nographic -monitor unix:/tmp/qemu-mon.sock,server,nowait
guest# echo 0 > /sys/bus/pci/slots/1/power
host$ echo "pcie_surprise_del edu0" | socat - unix-connect:/tmp/qemu-mon.sock
This is the test I am trying to solve.
Without patch 2 the safe removal never returns. With it, pciehp_isr()
schedules ctrl->disconnect_work, which walks the bus and schedules
pdev->disconnect_work; the wait in the POC driver completes and
remove() proceeds.
Open questions
- Is this a viable approach?
[1] https://lore.kernel.org/all/20260826194815.GA1552818@bhelgaas/
[2] https://lore.kernel.org/all/aHlZE18kPuHuDtTT@wunner.de/
[3] https://gitlab.com/abhinkop/qemu/-/commits/suprise-removal
Assisted-by: LLM
Abhin Parekadan Jose (2):
PCI: pciehp: Report surprise removal from pciehp_isr()
misc: Add edu_srpoc surprise removal POC driver
Michael S. Tsirkin (1):
PCI: Report surprise removal event
drivers/misc/Makefile | 1 +
drivers/misc/edu_srpoc.c | 169 +++++++++++++++++++++++++++++++
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 56 ++++++++--
drivers/pci/pci.h | 12 +++
include/linux/pci.h | 45 ++++++++
6 files changed, 276 insertions(+), 8 deletions(-)
create mode 100644 drivers/misc/edu_srpoc.c
--
2.51.1
next reply other threads:[~2026-09-05 18:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 18:38 Abhin Parekadan Jose [this message]
2026-09-05 18:38 ` [PATCH RFC 1/3] PCI: Report surprise removal event Abhin Parekadan Jose
2026-09-05 18:46 ` sashiko-bot
2026-09-05 18:38 ` [PATCH RFC 2/3] PCI: pciehp: Report surprise removal from pciehp_isr() Abhin Parekadan Jose
2026-09-05 18:52 ` sashiko-bot
2026-09-12 15:57 ` Michael S. Tsirkin
2026-09-05 18:39 ` [PATCH RFC 3/3] misc: Add edu_srpoc surprise removal POC driver Abhin Parekadan Jose
2026-09-05 18:50 ` 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=20260905183905.997833-1-abhinjoses@gmail.com \
--to=abhinjoses@gmail.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--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=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 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.