All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.