[PATCH] net/memif: fix race between interrupt thread and stop

[Sriram Yagnaraman]

> -----Original Message-----
> From: David Marchand <david.marchand at redhat.com>
> Sent: Wednesday, 4 November 2026 17:43
> To: Sriram Yagnaraman <sriram.yagnaraman at ericsson.com>
> Cc: dev at dpdk.org; Jakub Grajciar <jgrajcia at cisco.com>; Stephen Hemminger
> <stephen at networkplumber.org>; stable at dpdk.org
> Subject: Re: [PATCH] net/memif: fix race between interrupt thread and stop
> 
> On Fri, 30 Oct 2026 at 11:22, Sriram Yagnaraman
> <sriram.yagnaraman at ericsson.com> 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: stable at dpdk.org
> >
> > Reported-by: Stephen Hemminger <stephen at networkplumber.org>
> > Suggested-by: Stephen Hemminger <stephen at networkplumber.org>
> > Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman at ericsson.com>
> 
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.dpdk.org%2Fproject%2Fdpdk%2Fpatch%2F20261104164153.167432
> 9-1-
> david.marchand%40redhat.com%2F&data=05%7C02%7Csriram.yagnaraman
> %40ericsson.com%7C6fa63dfec8a649cc8e0008df3a92b277%7C92e84cebfbf
> d47abbe52080c6b87953f%7C0%7C0%7C639294073930934928%7CUnkno
> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> data=1nsnyrcY0rxAgsQI1w5NqEVNbMxJnipJ8UTrE8j3y1s%3D&reserved=0
> 
> 
> --
> David Marchand

The above patch is correct and needs to be taken in, but it fixes the listener socket path (socket->intr_handle / memif_listener_handler in memif_socket_remove_device).
From the logs, I feel the CI autotest SIGSEGV is a different race: the control channel teardown (cc->intr_handle / memif_intr_handler) racing memif_disconnect() from dev_stop.

Anyhow, I am working on a simpler fix for the second race (assuming your patch doesn't solve the CI crashes).