On Tue, 3 Feb 2026 at 09:24, Morten Brørup <[email protected]> wrote: > > > From: Scott Mitchell <[email protected]> > > > > 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: [email protected] > > Cc: [email protected] > > > > Signed-off-by: Scott Mitchell <[email protected]> > > 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 <[email protected]> > > 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
