On Sun, 24 Jun 2018, Lukas Wunner wrote: > 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. Good. > 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. Ha! I was looking at it yesterday for unrelated reasons and was wondering about the huge amount of users .... > 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. Sure > 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. Exactly. Thanks, tglx
