On 01/03/17 03:26 PM, Keith Busch wrote: > I think this is from using the managed device resource API to request the > irq actions. The scope of the resource used to be tied to the pci_dev's > dev, but now it's the new switchec class dev, which has a different > lifetime while open references exist, so it's not releasing the irq's.
The scope of the IRQ was originally tied to the pci_dev. Then in v4 I tied it to the switchtec device in order to try and keep using the pci device after unbind. This didn't work, so I switched it back to using the pci_dev. (This seems to be the way most drivers work anyway.) > One thing about the BUG_ON that is confusing me is how it's getting > to free_msi_irq's BUG in v4 or v5. I don't see any part releasing the > allocated ones. Maybe the devres API is harder to use than having the > driver manage all the resources... free_msi_irqs seems to be called via pci_disable_device in pcim_release which devres will call during release of the PCI device and before all the references to the pci_dev are freed (I tried adding an extra get_device which gets put in the child devices release -- this didn't work): [ 1079.845616] Call Trace: [ 1079.845652] ? pcim_release+0x35/0x96 [ 1079.845691] ? release_nodes+0x15b/0x17c [ 1079.845730] ? device_release_driver_internal+0x12d/0x1cb [ 1079.845771] ? unbind_store+0x59/0x89 [ 1079.845809] ? kernfs_fop_write+0xe7/0x129 [ 1079.845847] ? __vfs_write+0x1c/0xa2 [ 1079.845885] ? kmem_cache_alloc+0xc5/0x131 [ 1079.845923] ? fput+0xd/0x7d [ 1079.845958] ? filp_close+0x5a/0x61 [ 1079.845993] ? vfs_write+0xa2/0xe4 [ 1079.846028] ? SyS_write+0x48/0x73 [ 1079.846066] ? entry_SYSCALL_64_fastpath+0x13/0x94 v5 is correct because it registers the irqs against the pci_dev (with devm_request_irq) and thus they get freed in time as part of the devres unwind. Logan
