Agreed on the related pthread_mutex_init bug. In this patch dev->mutex is only ever locked by the primary process: the MP handler runs in the primary's EAL dispatch thread, and the teardown path in virtio_user_dev_uninit() is primary-only. The secondary communicates via rte_mp_request_sync() over the EAL socket and never calls pthread_mutex_lock() on dev->mutex directly.
That said, POSIX requires PTHREAD_PROCESS_SHARED for a mutex stored in shared memory regardless of which processes actually lock it, and other DPDK multiprocess-aware code already uses rte_thread_mutex_init_shared() for shared-memory mutexes. The pthread_mutex_init(&dev->mutex, NULL) call predates this patch but since this patch explicitly documents the lock's role I will fix the initialisation in v2: - pthread_mutex_init(&dev->mutex, NULL); + rte_thread_mutex_init_shared(&dev->mutex); On Wed, Jun 24, 2026 at 8:46 PM Stephen Hemminger < [email protected]> wrote: > On Wed, 24 Jun 2026 08:57:41 +0000 > Samar Yadav <[email protected]> wrote: > > > @@ -865,9 +913,15 @@ virtio_user_dev_uninit(struct virtio_user_dev *dev) > > > > rte_mem_event_callback_unregister(VIRTIO_USER_MEM_EVENT_CLB_NAME, > dev); > > > > + /* > > + * Serialize closing/freeing the kick/call fd arrays against the MP > > + * handler, which reads them under the same lock to share them with > > + * secondary processes. > > + */ > > + pthread_mutex_lock(&dev->mutex); > > virtio_user_dev_uninit_notify(dev); > > - > > virtio_user_free_vrings(dev); > > + pthread_mutex_unlock(&dev->mutex); > > > > free(dev->ifname); > > Related bug. virtio_user is not initializing mutex as safe between > processes. See rte_thread_mutex_init_shared() vs pthread_mutex_init() >
