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?
