[Bug 300062] linuxkpi: pci_release_region() never removes pdev->mmio entries ("driver did not clean up; leaking mmio resources" on detach)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=300062

--- Comment #2 from Michal Kilijanek <michal+freebsd@kilijanek.pl> ---
Follow-up: runtime analysis and test of the proposed fix.

DTrace on iwlwifi detach (devctl detach), before the fix:

  lkpi_pcim_iomap_table_release()
    pci_iounmap(res=0xfffff800fd700000)
  lkpi_pci_devres_release()
    pci_release_region(bar=0)
      compare loop: rman_get_bushandle(mmio->res) -> 0xfffff800fd700000
      bus_release_resource_old(res=0xfffff80001a53580)
  release_common: pdev->mmio first entry res=0xfffff80001a53580 rid=0x10
  -> "driver did not clean up; leaking mmio resources"

Correction to my description: the BAR resource itself IS released, exactly
once, by pci_release_region().  What leaks is only the pci_mmio_region list
entry, which is left pointing at the already released resource.

At attach, pcim_request_all_regions() allocates BAR 0 (0xfffff80001a53580)
and the following pcim_iomap(pdev, 0) returns the same entry (the
"duplicate mapping" path in _lkpi_pci_iomap()).  So there is one entry
shared by the region request and the iomap.

A related latent issue: pci_iounmap() is called with the mapped address
(0xfffff800fd700000), but with want_iomap_res set (iwlwifi calls
linuxkpi_pcim_want_to_use_bus_functions()) it compares that address against
mmio->res (a struct resource *), so it never matches and is a no-op.  Today
that is what keeps the shared resource from being released twice.  If only
iounmap were "fixed" to match, pci_iounmap() and pci_release_region() would
both release BAR 0.

With the attached one-line fix (compare rle->res with mmio->res), on main
175595ba6 with GENERIC + the LinuxKPI NAPI change from freebsd-src PR #2497,
INVARIANTS and WITNESS enabled:

  pci_release_region(bar=0)
    bus_release_resource_old(res=0xfffff80001a4b580)    <- once
  release_common: pdev->mmio empty

- 3x `devctl detach iwlwifi0` / `devctl attach pci0:3:0:0`, each followed by
  re-association with traffic verified over wlan0: 0 "leaking mmio
  resources" messages (previously one per detach), no panic, no KASSERT.

-- 
You are receiving this mail because:
You are the assignee for the bug.