RE: [PATCH v3 1/6] test/soring: fix buffer overflow warnings with LTO

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 16 January 2026 07.46
> 
> When building with LTO (Link Time Optimization), GCC performs
> aggressive cross-compilation-unit inlining. This causes the compiler
> to analyze all code paths in __rte_ring_do_dequeue_elems(), including
> the 16-byte element path (__rte_ring_dequeue_elems_128), even when
> the runtime element size is only 4 bytes.
> 
> The static analyzer sees that the 16-byte path would copy
> 32 elements * 16 bytes = 512 bytes into a 128-byte buffer
> (uint32_t[32]),
> triggering -Wstringop-overflow warnings.
> 
> The existing #pragma GCC diagnostic suppression in rte_ring_elem_pvt.h
> doesn't help because with LTO the warning context shifts to the test
> file where the inlined code is instantiated.
> 
> Fix by sizing all buffers passed to soring acquire/dequeue functions
> for the worst-case element size (16 bytes = 4 * sizeof(uint32_t)).
> This satisfies the static analyzer without changing runtime behavior.

Using wildly oversized buffers doesn't seem like a recommendable solution.
If the ring library is ever updated to support cache size elements (64 byte), the buffers would have to be oversize by factor 16.

Maybe adding __rte_assume(sor->esize == sizeof(uint32_t)); immediately before calling each of the affected soring functions would fix the problem instead?

It's only a test application, so oversized buffers as a workaround is acceptable.

But if it serves as guidance for real applications, a better solution/workaround would be preferable.

> 
> Bugzilla ID: 1458
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  app/test/test_soring.c | 29 ++++++++++++++++++++++-------
>  1 file changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/app/test/test_soring.c b/app/test/test_soring.c
> index 3c1944424e..96be3935d4 100644
> --- a/app/test/test_soring.c
> +++ b/app/test/test_soring.c
> @@ -31,6 +31,19 @@
> 
>  #define MAX_ACQUIRED 20
> 
> +/*
> + * Buffer scaling factor for static analyzer appeasement.
> + *
> + * With LTO, GCC analyzes all code paths in
> __rte_ring_do_dequeue_elems(),
> + * including the 16-byte element path, even when runtime esize is
> smaller.
> + * Buffers passed to soring acquire/dequeue must be sized for the
> worst-case
> + * element size (16 bytes) to avoid -Wstringop-overflow warnings.
> + *
> + * Scale factor of 4 converts uint32_t count to 16-byte element
> capacity:
> + * N elements * 4 * sizeof(uint32_t) = N * 16 bytes
> + */
> +#define SORING_TEST_BUFSIZE(n) ((n) * 4)
> +
>  #define SORING_TEST_ASSERT(val, expected) do { \
>  	RTE_TEST_ASSERT(expected == val, \
>  			"%s: expected %u got %u\n", #val, expected, val); \
> @@ -58,7 +71,8 @@ move_forward_stage(struct rte_soring *sor,
>  {
>  	uint32_t acquired;
>  	uint32_t ftoken;
> -	uint32_t *acquired_objs[MAX_ACQUIRED];
> +	/* Sized for 16-byte elements to satisfy LTO static analysis */
> +	uint32_t *acquired_objs[SORING_TEST_BUFSIZE(MAX_ACQUIRED)];
> 
>  	acquired = rte_soring_acquire_bulk(sor, acquired_objs, stage,
>  			num_packets, &ftoken, NULL);
> @@ -149,12 +163,13 @@ test_soring_stages(void)
>  {
>  	struct rte_soring *sor = NULL;
>  	struct rte_soring_param prm;
> -	uint32_t objs[32];
> -	uint32_t rcs[32];
> -	uint32_t acquired_objs[32];
> -	uint32_t acquired_rcs[32];
> -	uint32_t dequeued_rcs[32];
> -	uint32_t dequeued_objs[32];
> +	/* Buffers sized for 16-byte elements to satisfy LTO static
> analysis */
> +	uint32_t objs[SORING_TEST_BUFSIZE(32)];
> +	uint32_t rcs[SORING_TEST_BUFSIZE(32)];
> +	uint32_t acquired_objs[SORING_TEST_BUFSIZE(32)];
> +	uint32_t acquired_rcs[SORING_TEST_BUFSIZE(32)];
> +	uint32_t dequeued_rcs[SORING_TEST_BUFSIZE(32)];
> +	uint32_t dequeued_objs[SORING_TEST_BUFSIZE(32)];
>  	size_t ssz;
>  	uint32_t stage, enqueued, dequeued, acquired;
>  	uint32_t i, ftoken;
> --
> 2.51.0