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

[Sriram Yagnaraman]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Wednesday, 4 November 2026 17:07
> 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; David Marchand
> <david.marchand at redhat.com>
> Subject: Re: [PATCH] net/memif: fix race between interrupt thread and stop
> 
> Hello,
> 
> 30/10/2026 11:22, Sriram Yagnaraman:
> > 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.
> 
> It seems the teardown is too much complex.
> We can probably make something simpler with a re-design.
> I'm not sure about applying this big fix on top of a fragile design.
> I'm aware it may be a big task.
> Tell us if you think the teardown can be better fixed easily.
> 
> Otherwise I suggest disabling the memif autotest from the fast tests series
> which runs in CI.
> What do you think?
> 

I agree, a redesign is warranted. For now, I did, what I think, is a better fix: https://patches.dpdk.org/project/dpdk/patch/20261105112026.432015-1-sriram.yagnaraman@ericsson.com/
If we conclude that even that is too complex, we can disable the memif autotest for now, I can send an RFC for a slightly bigger redesign later.