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

Stephen Hemminger
2026-01-20T14:34:20Z

On Tue, 20 Jan 2026 09:49:44 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, 19 January 2026 23.48
> >
> > On Fri, 16 Jan 2026 10:32:52 +0100
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > > 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 element size is not an inline function parameter, but fetched from the "esize" field in the rte_soring structure, so the compiler cannot see that the element size is 4 bytes. And thus it needs to consider all possible element sizes.
>
> > > >
> > > > 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.
> >
> > The analysis (from AI) is that compiler is getting confused.
>
> That would be my analysis too.
>
> > Since there is no good
> > way other than turning of LTO for the test to tell the compiler
>
> There is another way to tell the compiler: __rte_assume()

Tried that but it doesn't work because doesn't get propagated deep enough to impact here.