On Wed, 24 Jun 2026 08:16:10 -0700 Stephen Hemminger <[email protected]> wrote:
> > + /* > > + * 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); > > Related bug. virtio_user is not initializing mutex as safe between > processes. See rte_thread_mutex_init_shared() vs pthread_mutex_init() 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); Samar Yadav
