From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 1875] mlx5: pthread mutex in shared memory missing PTHREAD_PROCESS_SHARED
Date: Fri, 30 Jan 2026 16:33:08 +0000 [thread overview]
Message-ID: <bug-1875-3@http.bugs.dpdk.org/> (raw)
http://bugs.dpdk.org/show_bug.cgi?id=1875
Bug ID: 1875
Summary: mlx5: pthread mutex in shared memory missing
PTHREAD_PROCESS_SHARED
Product: DPDK
Version: 25.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: stephen@networkplumber.org
Target Milestone: ---
This is the mlx5 subset of bugzilla 662
The mlx5 specific analysis was:
## MLX5 Driver PTHREAD_PROCESS_SHARED Issue
### Summary
The mlx5 driver has pthread mutexes in shared memory that are initialized
without `PTHREAD_PROCESS_SHARED`, which causes undefined behavior when used
across multiple processes.
### Affected Mutexes
1. **`sh->txpp.mutex`** (`drivers/net/mlx5/mlx5.c`, line 1846)
- Location: `struct mlx5_dev_txpp` inside `struct mlx5_dev_ctx_shared`
- Purpose: Pacing create/destroy mutex for Tx packet pacing
2. **`sh->lwm_config_lock`** (`drivers/net/mlx5/mlx5.c`, line 1963)
- Location: `struct mlx5_dev_ctx_shared`
- Purpose: Low watermark configuration lock
### Why This Is a Problem
The `mlx5_dev_ctx_shared` structure is allocated via `mlx5_malloc(MLX5_MEM_ZERO
| MLX5_MEM_RTE, ...)` which uses hugepage-backed shared memory. This shared
context is accessible by both primary and secondary processes.
While the shared context is only **allocated** in the primary process (enforced
by assertion at line 1826), secondary processes can obtain a reference to this
shared context and potentially call operations that lock these mutexes.
Per POSIX, mutexes in shared memory accessed by multiple processes must be
initialized with `PTHREAD_PROCESS_SHARED` attribute. Without this,
synchronization between processes is undefined behavior.
### Note
A third mutex, `mlx5_dev_ctx_list_mutex` (line 201), is a static global
variable and is **not affected** since each process has its own copy.
### Suggested Fix
Initialize the mutexes with `PTHREAD_PROCESS_SHARED`:
```c
static void
mlx5_init_shared_mutex(pthread_mutex_t *mutex)
{
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
pthread_mutex_init(mutex, &attr);
pthread_mutexattr_destroy(&attr);
}
```
Then replace:
```c
pthread_mutex_init(&sh->txpp.mutex, NULL);
pthread_mutex_init(&priv->sh->lwm_config_lock, NULL);
```
With:
```c
mlx5_init_shared_mutex(&sh->txpp.mutex);
mlx5_init_shared_mutex(&priv->sh->lwm_config_lock);
```
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2026-01-30 16:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-1875-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.