Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

Thomas Gleixner
2021-12-14T17:03:54Z

On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
>> On 10:41-20211214, Thomas Gleixner wrote:
> [ 13.478122] Call trace:
> [ 13.509042] msi_device_destroy_sysfs+0x18/0x88
> [ 13.509058] msi_domain_free_irqs+0x34/0x58
> [ 13.509064] pci_msi_teardown_msi_irqs+0x30/0x3c
> [ 13.509072] free_msi_irqs+0x78/0xd4
> [ 13.509077] pci_disable_msix+0x138/0x164
> [ 13.529930] pcim_release+0x70/0x238
> [ 13.529942] devres_release_all+0x9c/0xfc
> [ 13.529951] device_release_driver_internal+0x1a0/0x244
> [ 13.542725] device_release_driver+0x18/0x24
> [ 13.542741] iwl_req_fw_callback+0x1a28/0x1ddc [iwlwifi]
> [ 13.552308] request_firmware_work_func+0x50/0x9c
> [ 13.552320] process_one_work+0x194/0x25c
>
> That's not a driver problem, that's an ordering issue vs. the devres
> muck. Let me go back to the drawing board. Sigh...

Which is pretty obvious why:

pcim_enable_device()
devres_alloc(pcim_release...);
...
pci_irq_alloc()
msi_setup_device_data()
devres_alloc(msi_device_data_release, ...)

and once the device is released:

msi_device_data_release()
...
pcim_release()
pci_disable_msi[x]()

Groan....