public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Pali Rohár" <pali@kernel.org>,
	"Johan Hovold" <johan+linaro@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Xiaowei Song" <songxiaowei@hisilicon.com>,
	"Binghui Wang" <wangbinghui@hisilicon.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Ryder Lee" <ryder.lee@mediatek.com>,
	"Jianjun Wang" <jianjun.wang@mediatek.com>,
	linux-pci@vger.kernel.org, "Krzysztof Wilczyński" <kw@linux.com>,
	"Ley Foon Tan" <ley.foon.tan@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented?
Date: Fri, 22 Jul 2022 18:06:07 +0100	[thread overview]
Message-ID: <87k085xekg.wl-maz@kernel.org> (raw)
In-Reply-To: <20220722143905.GA1818909@bhelgaas>

Hi Bjorn,

On Fri, 22 Jul 2022 15:39:05 +0100,
Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
> [+cc Marc, can you clarify when we need irq_dispose_mapping()?]

In general, interrupt controllers should not have to discard mappings
themselves, just like they rarely create mappings themselves. That's
usually a different layer that has created it (DT, for example).

The problem is that these mappings persist even if the interrupt has
been released by the driver (it called free_irq()), and the IRQ number
can be further reused. The client driver could dispose of the mapping
after having released the IRQ, but nobody does that in practice.

From the point of view of the controller, there is no simple way to
tell when an interrupt is "unused". And even if a driver was
overzealous and called irq_dispose_mapping() on all the possible
mappings (and made sure no mapping could be created in parallel), this
could result in a bunch of dangling pointers should a client driver
still have the interrupt requested.

Fixing this is pretty hard, as IRQ descriptors are leaky (you can
either have a pointer to one, or just an IRQ number -- they are
strictly equivalent). So in general, being able to remove an interrupt
controller driver is at best fragile, and I'm trying not to get more
of this in the tree.

Hope this helps,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-07-22 17:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 19:54 Why set .suppress_bind_attrs even though .remove() implemented? Bjorn Helgaas
2022-07-21 20:46 ` Pali Rohár
2022-07-21 20:48   ` Conor.Dooley
2022-07-21 22:21   ` Bjorn Helgaas
2022-07-21 22:48     ` Pali Rohár
2022-07-22 13:26     ` Johan Hovold
2022-07-22 14:38       ` Bjorn Helgaas
2022-07-25 13:25         ` Johan Hovold
2022-07-25 14:43           ` Marc Zyngier
2022-07-25 15:18             ` Johan Hovold
2022-07-25 17:35               ` Marc Zyngier
2022-07-26  9:56                 ` Johan Hovold
2022-07-27 19:57                   ` Bjorn Helgaas
2022-07-28 12:17                     ` Johan Hovold
2024-10-17  5:23                       ` Manivannan Sadhasivam
2024-10-17  7:50                         ` Marc Zyngier
2024-10-17  8:25                           ` Manivannan Sadhasivam
2024-10-17  8:48                             ` Marc Zyngier
2024-10-17  9:30                               ` Manivannan Sadhasivam
2024-10-17  9:56                                 ` Marc Zyngier
2022-09-27 15:27                 ` Lorenzo Pieralisi
2022-09-28  6:36                   ` Johan Hovold
2022-07-22 14:39     ` Bjorn Helgaas
2022-07-22 17:06       ` Marc Zyngier [this message]
2022-07-22 17:17         ` Bjorn Helgaas
2022-07-24  9:38           ` Marc Zyngier
2022-07-25 20:18             ` Florian Fainelli
2022-07-25 17:49         ` Conor.Dooley
2022-07-26  7:26           ` Marc Zyngier

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=87k085xekg.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=helgaas@kernel.org \
    --cc=jianjun.wang@mediatek.com \
    --cc=johan+linaro@kernel.org \
    --cc=kishon@ti.com \
    --cc=kw@linux.com \
    --cc=ley.foon.tan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=ryder.lee@mediatek.com \
    --cc=songxiaowei@hisilicon.com \
    --cc=thierry.reding@gmail.com \
    --cc=wangbinghui@hisilicon.com \
    /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