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: <e3fb313a-f634-3429-05ea-ebaa98809c71@microchip.com>
Date:   Mon, 25 Jul 2022 17:49:05 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <maz@...nel.org>, <helgaas@...nel.org>
CC:     <pali@...nel.org>, <johan+linaro@...nel.org>, <kishon@...com>,
        <songxiaowei@...ilicon.com>, <wangbinghui@...ilicon.com>,
        <thierry.reding@...il.com>, <ryder.lee@...iatek.com>,
        <jianjun.wang@...iatek.com>, <linux-pci@...r.kernel.org>,
        <kw@...ux.com>, <ley.foon.tan@...el.com>,
        <linux-kernel@...r.kernel.org>, <Daire.McNamara@...rochip.com>
Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented?

On 22/07/2022 18:06, Marc Zyngier wrote:
> Hi Bjorn,
> 
> 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.
> 

Sorry to butt back in here - but I am taking this to mean that rather
than add a remove callback for the microchip pci controller driver when
making it buildable as a module it would instead be better to forgo that
entirely and prevent unloading the module (since it does INTX & MSI).

Would that be an accurate assessment?
Thanks,
Conor.