On Sat, 24 Oct 2026 at 16:11, Burakov, Anatoly <[email protected]> wrote: > > On 10/24/2026 3:21 PM, David Marchand wrote: > > The FD leak warnings recently added have revealed an interesting issue. > > > > An interrupt handle is allocated and living usually in a bus device object > > (or some standalone code, like the alarm code). > > All the logic around the referenced FDs in this object are specific to > > the callers, and those FDs must then be closed in the callers context. > > > > On the other hand, the interrupt subsystem works with copies of interrupt > > handle objects passed to it via rte_intr_callback_register/unregister. > > > > When releasing this clone of the interrupt handle, the FDs are reported > > as leaked, though there is no way for the interrupt subsystem itself to > > know what to do with those FDs. > > > > Instead of creating a clone, reference the interrupt handle directly. > > The callers are responsible for unregistering those handles, > > closing the FDs and freeing the handles. > > > > This change also switches the interrupt source lookup from FD based > > matching to pointer based matching. > > The original FD based matching allowed different intr_handle objects > > with the same FD to share an interrupt source. > > However, this was problematic: > > * the cloned handle stored in the source came from the first registrant, > > * the ucb_fn callback would receive this clone, not the (const) > > caller's handle, > > * with multiple handles for the same FD, later registrants would get > > the wrong handle in their callback, > > > > In practice, DPDK components use one intr_handle per FD, so pointer > > based matching simply enforces this existing invariant. > > The interrupt dispatch code continues to use FD based matching since > > epoll returns the FD, not the handle pointer. > > > > The unregister callback (ucb_fn) signature is updated to take a const > > pointer, reflecting that the interrupt subsystem no longer owns the > > handle. Note that with this change, the intr_handle parameter passed > > to ucb_fn is the same pointer the caller registered with, callers > > can simply use their own handle from cb_arg instead. > > > > Signed-off-by: David Marchand <[email protected]> > > --- > > Acked-by: Anatoly Burakov <[email protected]> > > However, my patches fixed the issue in instance_dup without removing the > API. Those fixes should probably be backported to stable in some form.
Indeed. I can take your first two patches right after the 2 first fixes in this series, right before removing the duplicate API. That's just a little rebase for me (I'll double check compilation is not broken between patches). WDYT? -- David Marchand
