> -----Original Message----- > From: David Marchand <[email protected]> > Sent: Wednesday, 4 November 2026 17:43 > To: Sriram Yagnaraman <[email protected]> > Cc: [email protected]; Jakub Grajciar <[email protected]>; Stephen Hemminger > <[email protected]>; [email protected] > Subject: Re: [PATCH] net/memif: fix race between interrupt thread and stop > > 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://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).
