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.
--
Thanks,
Anatoly
