patch 'mem: fix data race in Linux hugepage prefault' has been queued to stable release 24.11.7
luca.boccassi at gmail.com
luca.boccassi at gmail.com
Thu Jun 11 15:20:17 CEST 2026
Hi,
FYI, your patch has been queued to stable release 24.11.7
Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 06/13/26. So please
shout if anyone has objections.
Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.
Queued patches are on a temporary branch at:
https://github.com/bluca/dpdk-stable
This queued commit can be viewed at:
https://github.com/bluca/dpdk-stable/commit/c63517818aaa48ba2370c37bebfc6cce2a83f042
Thanks.
Luca Boccassi
---
>From c63517818aaa48ba2370c37bebfc6cce2a83f042 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen at networkplumber.org>
Date: Mon, 1 Jun 2026 09:00:18 -0700
Subject: [PATCH] mem: fix data race in Linux hugepage prefault
[ upstream commit 0c0f70f98dcf5b860b2e422ad20f40cc9f1d3705 ]
The prefault step in alloc_seg() reads a value from the hugepage and
writes it back unchanged to force the kernel to commit the backing
page. The read and write were not atomic, which races with concurrent
access to the same physical page from a secondary process attaching
to the hugetlbfs-backed mapping during rte_eal_init().
Replace the non-atomic load+store with a single atomic fetch-or of
zero. This touches the page with an atomic read-modify-write without
changing its contents, eliminating the race while preserving the
original intent of forcing a write fault.
Fixes: 0f1631be24bd ("mem: fix page fault trigger")
Reported-by: Michal Sieron <michal.sieron at nokia.com>
Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
---
.mailmap | 1 +
lib/eal/linux/eal_memalloc.c | 8 +++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/.mailmap b/.mailmap
index 9824d79d20..80713f22dc 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1050,6 +1050,7 @@ Michal Michalik <michal.michalik at intel.com>
Michał Mirosław <michal.miroslaw at atendesoftware.pl> <mirq-linux at rere.qmqm.pl>
Michal Nowak <michal2.nowak at intel.com>
Michal Schmidt <mschmidt at redhat.com>
+Michal Sieron <michal.sieron at nokia.com>
Michal Swiatkowski <michal.swiatkowski at intel.com>
Michal Wilczynski <michal.wilczynski at intel.com>
Michel Machado <michel at digirati.com.br>
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index 4239aedc85..d64ff2554c 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -28,6 +28,7 @@
#include <linux/falloc.h>
#include <linux/mman.h> /* for hugetlb-related mmap flags */
+#include <rte_atomic.h>
#include <rte_common.h>
#include <rte_log.h>
#include <rte_eal.h>
@@ -640,10 +641,11 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
/* we need to trigger a write to the page to enforce page fault and
* ensure that page is accessible to us, but we can't overwrite value
- * that is already there, so read the old value, and write itback.
- * kernel populates the page with zeroes initially.
+ * that is already there.
+ * Use an atomic OR with zero to touch the page without changing its contents.
*/
- *(volatile int *)addr = *(volatile int *)addr;
+ (void)rte_atomic_fetch_or_explicit((__rte_atomic uint64_t *)addr, 0,
+ rte_memory_order_relaxed);
iova = rte_mem_virt2iova(addr);
if (iova == RTE_BAD_PHYS_ADDR) {
--
2.47.3
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2026-06-11 14:20:04.016651323 +0100
+++ 0068-mem-fix-data-race-in-Linux-hugepage-prefault.patch 2026-06-11 14:20:01.282747635 +0100
@@ -1 +1 @@
-From 0c0f70f98dcf5b860b2e422ad20f40cc9f1d3705 Mon Sep 17 00:00:00 2001
+From c63517818aaa48ba2370c37bebfc6cce2a83f042 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit 0c0f70f98dcf5b860b2e422ad20f40cc9f1d3705 ]
+
@@ -18 +19,0 @@
-Cc: stable at dpdk.org
@@ -28 +29 @@
-index 118dfa0ff9..364e027894 100644
+index 9824d79d20..80713f22dc 100644
@@ -31,2 +32,2 @@
-@@ -1094,6 +1094,7 @@ Michal Mazurek <maz at semihalf.com>
- Michal Michalik <michal.michalik at intel.com>
+@@ -1050,6 +1050,7 @@ Michal Michalik <michal.michalik at intel.com>
+ Michał Mirosław <michal.miroslaw at atendesoftware.pl> <mirq-linux at rere.qmqm.pl>
@@ -38 +39 @@
- Michał Mirosław <michal.miroslaw at atendesoftware.pl> <mirq-linux at rere.qmqm.pl>
+ Michel Machado <michel at digirati.com.br>
@@ -40 +41 @@
-index a39bc31c7b..7359a41d3f 100644
+index 4239aedc85..d64ff2554c 100644
@@ -43 +44 @@
-@@ -25,6 +25,7 @@
+@@ -28,6 +28,7 @@
@@ -51 +52 @@
-@@ -597,10 +598,11 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
+@@ -640,10 +641,11 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
More information about the stable
mailing list