[PATCH v17 1/2] eal: remove alloc_size from rte_lcore_var_alloc

[David Marchand]

On Tue, 3 Feb 2026 at 09:24, Morten Brørup <mb at smartsharesystems.com> wrote:
>
> > From: Scott Mitchell <scott.k.mitch1 at gmail.com>
> >
> > The __rte_alloc_size(1) attribute on rte_lcore_var_alloc() is
> > semantically incorrect and causes false positives with FORTIFY_SOURCE
> > runtime checks.
> >
> > The attribute tells the compiler that the function returns a pointer
> > to 'size' bytes of usable memory. However, rte_lcore_var_alloc()
> > actually returns a handle to a per-lcore variable scheme. The
> > allocator internally allocates 'size' bytes per lcore
> > (size * RTE_MAX_LCORE total), partitioned into per-lcore sections.
> > The handle points to lcore 0's copy, and accessed via
> > RTE_LCORE_VAR_LCORE(lcore_id, handle) which computes:
> > handle + (lcore_id * RTE_MAX_LCORE_VAR). Access is expected
> > beyond 'size' bytes beyond the returned pointer when 'lcore_id != 0'
> > but FORTIFY_SOURCE may terminate the program due to out of bounds
> > access.
> >
> > This can be observed on CI with gcc 13.3.0 in lcore_var_autotest with
> > '*** buffer overflow detected ***: terminated' if pointer provenance
> > is preserved (e.g. if offsets avoid casting to uintptr_t).
> >
> > Fixes: 5bce9bed67ad ("eal: add static per-lcore memory allocation
> > facility")
> > Cc: mattias.ronnblom at ericsson.com
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: Scott Mitchell <scott.k.mitch1 at gmail.com>
>
> This patch could be separated from the RTE_PTR_ADD/SUB series.

I agree.
There were comments on patch 2, so I took this patch directly.

> Acked-by: Morten Brørup <mb at smartsharesystems.com>
>
> NB: Please keep this ACK for any new versions of this patch if the essence of the patch doesn't change.

Yes please, I restored acks from Mattias and Stephen.

Applied, thanks.


-- 
David Marchand