Bjorn Helgaas <helgaas@xxxxxxxxxx> writes:
> On Tue, Jun 30, 2020 at 12:39:08PM +0300, Andy Shevchenko wrote:
>> The problem here is in the original patch which relies on the
>> knowledge that fwnode is (was) not used anyhow specifically for ACPI
>> case. That said, it makes fwnode a dangling pointer which I
>> personally consider as a mine left for others. That's why the Fixes
>> refers to the initial commit. The latter just has been blasted on
>> that mine.
No. The original patch did not create a dangling pointer because fwnode
was not stored for IRQCHIP_FWNODE_NAMED and IRQCHIP_FWNODE_NAMED_ID type
nodes.
The fail was introduced in:
711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode")
> IIUC, you're saying this pattern:
>
> fwnode = irq_domain_alloc_named_id_fwnode(...)
> irq_domain = pci_msi_create_irq_domain(fwnode, ...)
> irq_domain_free_fwnode(fwnode)
>
> leaves a dangling fwnode pointer. That does look suspicious because
> __irq_domain_add() saves fwnode:
>
> irq_domain = pci_msi_create_irq_domain(fwnode, ...)
> msi_create_irq_domain(fwnode, ...)
> irq_domain_create_hierarchy(..., fwnode, ...)
> irq_domain_create_linear(fwnode, ...)
> __irq_domain_add(fwnode, ...)
> domain->fwnode = fwnode
>
> and irq_domain_free_fwnode() frees it. But I'm confused because there
> are several other instances of this pattern:
>
> bridge_probe() # arch/mips/pci/pci-xtalk-bridge.c
> mp_irqdomain_create()
> arch_init_msi_domain()
> arch_create_remap_msi_irq_domain()
> dmar_get_irq_domain()
> hpet_create_irq_domain()
> ...
>
> Are they all wrong? I definitely think it's a bad idea to keep a copy
> of a pointer after we free the data it points to. But if they're all
> wrong, I don't want to fix just one and leave all the others.
>
> Thomas, can you enlighten us?
Did so. And yes, all instances which do alloc/create/free are busted
since that commit.
Thanks,
tglx
