Re: [PATCH] eal: fix data race in hugepage prefault

[Thomas Monjalon <thomas@monjalon.net>]

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@dpdk.org
> 
> Reported-by: Michal Sieron <michal.sieron@nokia.com>
> Signed-off-by: Stephen Hemminger <stephen@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);
              ^                            ~~~~~~~~~~~