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

[Stephen Hemminger]

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

> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Monday, 19 January 2026 23.48
> > 
> > On Fri, 16 Jan 2026 10:32:52 +0100
> > Morten Brørup <mb at smartsharesystems.com> wrote:
> >   
> > > > From: Stephen Hemminger [mailto:stephen at 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.