On Fri, 30 Oct 2026 at 11:22, Sriram Yagnaraman
<[email protected]> wrote:
>
> The control-channel callback runs on the interrupt thread and calls
> memif_disconnect() when the peer hangs up. Nothing ordered this against
> an application thread stopping and closing the same port. When the peer
> of a loopback pair is stopped first, the callback can still be running
> memif_disconnect() while the port is closed and released, and then
> dereferences dev->data which is NULL. Seen as a SIGSEGV on the interrupt
> thread during memif_pmd_autotest teardown.
>
> Detach the control channel in memif_cc_detach(), called without cc_lock:
>
>   - take pmd->cc under cc_lock so only one caller owns it;
>   - on the interrupt thread (the callback itself) defer the free to the
>     pending-unregister callback, as before;
>   - on an application thread wait for a running callback with
>     rte_intr_callback_unregister_sync() so the device stays valid until
>     it returns, then free.
>
> memif_intr_handler() no longer disconnects a device that has already
> dropped this channel: it stops polling the fd and returns, letting the
> waiting application thread free the channel. Once memif_cc_detach()
> returns the handler cannot run for the device, so the queue and region
> teardown no longer needs cc_lock.
>
> Fixes: 09c7e63a71f9 ("net/memif: introduce memory interface PMD")
> Cc: [email protected]
>
> Reported-by: Stephen Hemminger <[email protected]>
> Suggested-by: Stephen Hemminger <[email protected]>
> Signed-off-by: Sriram Yagnaraman <[email protected]>

This driver dealing with interrupt handle is really complex (some
logic should probably move elsewhere... like an alarm handler maybe).

If the issue is a race between an application requesting device close,
and the interrupt thread invoking the interrupt handle callback, then
it means that the device close is not properly unregistering the
interrupt handle in the first place.
So my guts tells me that something like this should help:
https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/


-- 
David Marchand

Reply via email to