linux-kernel - Re: Why set .suppress_bind_attrs even though .remove() implemented?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <877d42df5t.wl-maz@kernel.org>
Date:   Sun, 24 Jul 2022 10:38:06 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Pali Rohár <pali@...nel.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Xiaowei Song <songxiaowei@...ilicon.com>,
        Binghui Wang <wangbinghui@...ilicon.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Ryder Lee <ryder.lee@...iatek.com>,
        Jianjun Wang <jianjun.wang@...iatek.com>,
        linux-pci@...r.kernel.org,
        Krzysztof Wilczyński <kw@...ux.com>,
        Ley Foon Tan <ley.foon.tan@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented?

On Fri, 22 Jul 2022 18:17:06 +0100,
Bjorn Helgaas <helgaas@...nel.org> wrote:
> 
> On Fri, Jul 22, 2022 at 06:06:07PM +0100, Marc Zyngier wrote:
> > On Fri, 22 Jul 2022 15:39:05 +0100,
> > Bjorn Helgaas <helgaas@...nel.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.
> 
> Thank you!
> 
> How do we identify an interrupt controller driver?  Apparently some of
> these PCIe controller drivers also include an interrupt controller
> driver, but I don't know what to look for to find them.

If you see a struct irq_chip somewhere, this is an interrupt
controller.  And yes, most of the PCIe RC drivers will have some sort
of interrupt controller driver for INTx support, as well as MSI when
the RC doesn't/cannot rely on the platform providing one.

It means that these PCIe RC drivers probably shouldn't be removable if
built as modules. Which I don't think is a big problem. You want
modularity to reduce the size of the kernel image and only load the
drivers the platform actually requires, saving memory in the process.
And for something as fundamental as an interrupt controller (and PCIe
in general), you probably want to keep it around for the lifetime of
the machine.

Thanks,

	M.

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