> -----Original Message----- > From: Thomas Monjalon <[email protected]> > Sent: Wednesday, 4 November 2026 17:07 > To: Sriram Yagnaraman <[email protected]> > Cc: [email protected]; Jakub Grajciar <[email protected]>; Stephen Hemminger > <[email protected]>; [email protected]; David Marchand > <[email protected]> > 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/[email protected]/ 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.
