On Fri, Jul 18, 2025 at 06:35:56AM +0200, Lukas Wunner wrote: > 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 Got it, thanks! -- MST
