On Tue, 16 Jun 2026 at 08:55, David Marchand <[email protected]> wrote: > > On Tue, 16 Jun 2026 at 01:55, Long Li <[email protected]> wrote: > > > > > > > > > This series refactors the bus cleanup infrastructure to reduce code > > > > duplication and fix resource leaks in several bus drivers. > > > > It should address the leak Thomas pointed at. > > > > > > > > The first part of the series (patches 1-8) addresses several bugs and > > > > inconsistencies: > > > > - Documentation and log message inconsistencies from earlier bus > > > > refactoring > > > > - Device list management issues in dma/idxd and bus/vdev > > > > - Resource leaks in PCI and VMBUS bus cleanup (mappings and > > > > interrupts) > > > > - Simplified device freeing in NXP buses (DPAA and FSLMC) > > > > - Deferred interrupt allocation to probe time (NXP buses, VMBUS) > > > > > > > > The core infrastructure changes (patches 9-10) introduce the generic > > > > cleanup > > > > framework: > > > > - Refactors unplug operations to be the counterpart of probe_device > > > > - Implements rte_bus_generic_cleanup() to centralize cleanup logic > > > > - Adds .free_device operation to struct rte_bus > > > > - Adds compile-time verification that rte_device is at offset 0 > > > > > > > > The final patches (11-13) convert remaining buses to use the generic > > > > cleanup > > > > helper: > > > > - DPAA bus: add unplug support > > > > - VMBUS bus: switch to embedded device name and add unplug support > > > > > > There is a hung on vmbus during device shutdown after applying the > > > series, I'm > > > looking into it. > > > > Turned out to be a test issue. Please see my comments on patch 08, the > > patch set tested well after that fix. > > Thanks a lot for testing! > > I'll fix this regression in the next revision.
Fyi Hemant, this series has a similar regression for dpaa/fslmc bus (interrupt handle allocated too late in the device probing flow). The implications seem greater than fixing vmbus though, as I am now finding bugs on the cleanup side (interrupt eventfd are never closed, for example). I'll think about how to fix it in the next revision, one option may be to leave dpaa/fslmc alone.. ? But in the long run, all bus drivers should behave consistently. I'll get back in this thread once I have a better view of the situation. -- David Marchand
