On Sun, Jun 24, 2018 at 11:49:10AM +0200, Thomas Gleixner wrote: > On Sun, 24 Jun 2018, Lukas Wunner wrote: > > When pciehp is converted to threaded IRQ handling, removal of unplugged > > devices below a PCIe hotplug port happens synchronously in the IRQ > > thread. Removal of devices typically entails a call to free_irq() by > > their drivers. > > Is this an actual mainline problem or did you discover that in course of > upcoming work? It's needed for upcoming work, specifically the pciehp event handling rework which will hopefully appear in 4.19, so nothing urgent. Doesn't hurt at all to let this bake in linux-next for a few weeks. There is something else, you introduced irq_wake_thread() four years ago with a92444c6b222 for sdhci/sdio, but for some reason it was never used. Before you or anyone else deletes it for lack of callers, please be aware that I'm making heavy use of it now in pciehp. I forgot to cc you on the relevant patch [17/32], but I'll bounce it to you in a minute in case you want to take a look at it. Of course this begs the question how irq_wake_thread() is serialized against __free_irq(), but it seems that's safe because irq_wake_thread() searches the action list while holding desc->lock: If it grabs the lock before __free_irq(), it'll just wake the thread normally. If it grabs the lock after __free_irq(), the action will be gone from the list, so irq_wake_thread() essentially becomes a no-op. Thanks, Lukas