[PATCH] net/virtio-user: fix eventfd sharing in secondary process
samar yadav
samaryadav5 at gmail.com
Fri Jun 26 10:05:13 CEST 2026
On Wed, 24 Jun 2026 08:16:10 -0700
Stephen Hemminger <stephen at networkplumber.org> 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
More information about the dev
mailing list