Re: [PATCH RFC v5 1/5] pci: report surprise removal event

[Lukas Wunner <lukas@wunner.de>]

On Thu, Jul 17, 2025 at 07:31:57PM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 17, 2025 at 10:12:03PM +0200, Lukas Wunner wrote:
> > pciehp_handle_presence_or_link_change() is called from pciehp_ist(),
> > the IRQ thread.  During safe removal the IRQ thread is busy in
> > pciehp_unconfigure_device() and waiting for the driver to unbind
> > from devices being safe-removed.
> 
> Confused. I thought safe removal happens in the userspace thread
> that wrote into sysfs?

No, the userspace thread synthesizes a DISABLE_SLOT event,
calls irq_wake_thread(), then waits for the IRQ thread to
finish handling that event.  See pciehp_sysfs_disable_slot().

Until 2018 we indeed brought down the slot in the userspace
thread, but that required locking between the workqueue fed
by the interrupt handler on the one hand and the userspace
thread on the other hand.  It was difficult to reason about
the code.

We had bug reports about slots flapping the link or presence
bits on slot bringdown that we could easily address by handling
everything in the IRQ thread, see 3943af9d01e9.  The same was
reported for slot bringup and addressed by 6c35a1ac3da6.

This wouldn't have been possible with the architecture prior
to 2018, at least not this easily.

Thanks,

Lukas