Re: [PATCH] net/virtio-user: fix eventfd sharing in secondary process

[samar yadav <samaryadav5@gmail.com>]

On Wed, 24 Jun 2026 08:16:10 -0700
Stephen Hemminger <stephen@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