[PATCH] eal: fix data race in hugepage prefault
Thomas Monjalon
thomas at monjalon.net
Mon Jun 1 12:03:41 CEST 2026
20/05/2026 19:08, Stephen Hemminger:
> 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")
> Cc: stable at dpdk.org
>
> Reported-by: Michal Sieron <michal.sieron at nokia.com>
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> ---
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> - *(volatile int *)addr = *(volatile int *)addr;
> + (void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
There is a compilation failure:
lib/eal/linux/eal_memalloc.c:604:8: error: address argument to atomic operation must be a pointer to _Atomic type ('int *' invalid)
(void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
^ ~~~~~~~~~~~
More information about the dev
mailing list