public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 2/2] genirq: Synchronize only with single thread on free_irq()
Date: Sun, 24 Jun 2018 13:34:03 +0200	[thread overview]
Message-ID: <20180624113403.GA22016@wunner.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1806241148030.8650@nanos.tec.linutronix.de>

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

  reply	other threads:[~2018-06-24 11:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-24  8:35 [PATCH v2 1/2] genirq: Update code comments wrt recycled thread_mask Lukas Wunner
2018-06-24  8:35 ` [PATCH v2 2/2] genirq: Synchronize only with single thread on free_irq() Lukas Wunner
2018-06-24  9:49   ` Thomas Gleixner
2018-06-24 11:34     ` Lukas Wunner [this message]
2018-06-24 12:12       ` Thomas Gleixner
2018-06-24 12:22   ` [tip:irq/core] " tip-bot for Lukas Wunner
2018-06-24  9:47 ` [PATCH v2 1/2] genirq: Update code comments wrt recycled thread_mask Thomas Gleixner
2018-06-24 12:21 ` [tip:irq/core] " tip-bot for Lukas Wunner

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=20180624113403.GA22016@wunner.de \
    --to=lukas@wunner.de \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox