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

Samar Yadav samaryadav5 at gmail.com
Fri Jun 26 09:37:10 CEST 2026


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 <
stephen at networkplumber.org> wrote:

> On Wed, 24 Jun 2026 08:57:41 +0000
> Samar Yadav <samaryadav5 at gmail.com> 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()
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260626/5b83530f/attachment.htm>


More information about the dev mailing list