[PATCH v2 03/12] interrupts: do not duplicate interrupt handles

Burakov, Anatoly anatoly.burakov at intel.com
Sat Oct 24 16:11:14 CEST 2026


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 <david.marchand at redhat.com>
> ---

Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>

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


More information about the dev mailing list