[PATCH v5 5/6] net/mlx5: fix LTO stringop-overflow warning

[Stephen Hemminger]

On Thu, 5 Feb 2026 14:43:35 +0100
Dariusz Sosnowski <dsosnowski at nvidia.com> wrote:

> On Tue, Jan 20, 2026 at 11:52:10AM -0800, Stephen Hemminger wrote:
> > When compiling with LTO (Link Time Optimization) enabled, GCC's
> > interprocedural analysis produces false positive warnings about
> > potential buffer overflow in mlx5dr_action_prepare_decap_l3_data():
> > 
> >   In function 'mlx5dr_action_prepare_decap_l3_data',
> >       inlined from 'mlx5dr_action_handle_tunnel_l3_to_l2',
> >       inlined from 'mlx5dr_action_create_reformat_hws':
> >   warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
> >     memcpy(dst, e_src, MLX5DR_ACTION_INLINE_DATA_SIZE);
> >   note: at offset [140, 524248] into destination object 'mh_data' of size 64
> > 
> > With LTO, the function chain is fully inlined, giving GCC visibility
> > into the 64-byte stack buffer 'mh_data'. However, GCC's static analysis
> > cannot determine that num_of_actions is constrained to either
> > DECAP_L3_NUM_ACTIONS_W_NO_VLAN (6) or DECAP_L3_NUM_ACTIONS_W_VLAN (7)
> > by the callers. It assumes worst-case bounds that greatly exceed the
> > buffer size.
> > 
> > Fix this by adding an explicit bounds check at function entry. The
> > valid values for num_of_actions are 6 (no VLAN) or 7 (with VLAN),
> > which produce maximum buffer usage well under 64 bytes:
> >   - offset 12 + (num_of_actions-3) * 8 + 2 = max 46 bytes for 7 actions
> > 
> > This provides GCC with the proof it needs that subsequent memcpy
> > operations are safe.
> > 
> > This is not a data path function - it executes only during flow rule
> > creation, so the additional check has no performance impact.
> > 
> > Bugzilla ID: 1710
> > Fixes: f8c8a6d8440d ("net/mlx5/hws: add action object")
> > Cc: stable at dpdk.org
> > 
> > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> > ---
> >  drivers/net/mlx5/hws/mlx5dr_action.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c b/drivers/net/mlx5/hws/mlx5dr_action.c
> > index b35bf07c3c..3b12506577 100644
> > --- a/drivers/net/mlx5/hws/mlx5dr_action.c
> > +++ b/drivers/net/mlx5/hws/mlx5dr_action.c
> > @@ -3620,6 +3620,20 @@ mlx5dr_action_prepare_decap_l3_data(uint8_t *src, uint8_t *dst,
> >  	uint8_t *e_src;
> >  	int i;
> >  
> > +	/*
> > +	 * Bounds check to help GCC LTO static analysis.
> > +	 *
> > +	 * When LTO inlines this into mlx5dr_action_handle_tunnel_l3_to_l2(),
> > +	 * GCC sees the 64-byte mh_data buffer but cannot prove num_of_actions
> > +	 * is bounded, causing false -Wstringop-overflow warnings.
> > +	 *
> > +	 * Valid num_of_actions values are DECAP_L3_NUM_ACTIONS_W_NO_VLAN (6)
> > +	 * or DECAP_L3_NUM_ACTIONS_W_VLAN (7). This check gives GCC the proof
> > +	 * it needs that the loop iterations stay within buffer bounds.
> > +	 */
> > +	if (unlikely(num_of_actions > DECAP_L3_NUM_ACTIONS_W_VLAN))
> > +		return;  
> 
> This function can be executed as part of fast path
> in async flow creation, so if possible
> I would avoid adding such a condition.
> 
> I tested locally with GCC 14.2.0 and it looks like
> if this condition is changed to equivalent __rte_assume(),
> then this condition is removed from generated code
> (https://godbolt.org/z/afx8jjr6Y as an example,
> code generated by LTO also optimizes the relevant code).
> __rte_assume() also fixes the LTO warning.
> 
> Could you please change the condition to equivalent __rte_assume()?
> 
> > +
> >  	/* num_of_actions = remove l3l2 + 4/5 inserts + remove extra 2 bytes
> >  	 * copy from end of src to the start of dst.
> >  	 * move to the end, 2 is the leftover from 14B or 18B
> > -- 
> > 2.51.0
> >   

Yes rte_assume works will resend