[RFC 0/3] common/cnxk: remove dependence on VLA

[RFC 0/3] common/cnxk: remove dependence on VLA

[Stephen Hemminger]

While looking at LTO compile failures, it looks like the cnxk common
code can be modified to not use VLA's. This fixes one of the compile
problems there.

Compile tested only!

Stephen Hemminger (3):
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings

 drivers/common/cnxk/meson.build    | 2 --
 drivers/common/cnxk/roc_aes.c      | 3 ++-
 drivers/common/cnxk/roc_platform.c | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

-- 
2.51.0

[RFC 1/3] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..e51cf532d7 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	RTE_ASSERT(data_word_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

[RFC 2/3] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

Re: [EXTERNAL] [RFC 2/3] common/cnxk: replace variable length array

[Harman Kalra]

Hi Stephen,

Please find response inline.

Thanks
Harman


________________________________________
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Friday, October 24, 2025 01:11
To: dev@dpdk.org
Cc: Stephen Hemminger; Nithin Kumar Dabilpuram; Kiran Kumar Kokkilagadda; Sunil Kumar Kori; Satha Koteswara Rao Kottidi; Harman Kalra
Subject: [EXTERNAL] [RFC 2/3] common/cnxk: replace variable length array

This fixes errors when compiled with LTO about large VLA. .. /drivers/common/cnxk/roc_platform. c: In function ‘irq_init’: .. /drivers/common/cnxk/roc_platform. c: 92: 14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!tq3Z1f8UAlXatG-dmV0aDgUiMX3k-TnFTMUNNDwBiTqsiDtPNHuGKbTZiCNYBjBSFK8C-DKdl6dvUuA0rM6hZ29mZZl_Zctb5JHJ$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>

-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-       (sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN                                                   \
+       (sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)


[HK] The value of MSIX_IRQ_SET_BUF_LEN should be derived from the maximum number of interrupts configured for a PCI device,
as obtained via plt_intr_max_intr_get(intr_handle), which internally uses the VFIO_DEVICE_GET_IRQ_INFO ioctl.
In contrast, PLT_MAX_RXTX_INTR_VEC_ID is a fixed default value representing the maximum number of interrupt vectors.
This mismatch may lead to unexpected behaviour as on certain platforms (like cnxk) where the PCI device's MSIX capability
may exceed PLT_MAX_RXTX_INTR_VEC_ID.

 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
--
2.51.0

[RFC 3/3] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLA's.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index daffc15afd..58ebf4c99f 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,8 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
-
 if meson.is_cross_build()
     soc_type = meson.get_external_property('platform', '')
 else
-- 
2.51.0

[PATCH v2 0/3] common/cnxk: remove variable length arrays

[Stephen Hemminger]

This series removes the use of variable length arrays (VLAs) from the
common/cnxk driver, allowing the VLA compiler warnings to be re-enabled.

VLAs are problematic for several reasons:
 - They can cause stack overflow with large or malicious inputs
 - They prevent certain compiler optimizations
 - They trigger warnings when compiled with LTO (-Wvla-larger-than=)
 - They are optional in C11 and removed in some C dialects

The first patch addresses the AES cipher function which always operates
on 16-byte blocks. The VLA is replaced with a fixed-size array using
the existing AES_HASH_KEY_LEN define, with an assertion to verify the
input constraint.

The second patch fixes the MSIX IRQ set buffer allocation. The original
code used a macro that expanded to a runtime function call, which the
compiler could not evaluate at compile time. This is replaced with
PLT_MAX_RXTX_INTR_VEC_ID, which matches the EAL's maximum interrupt
vector limit (512). This is consistent with how the EAL itself handles
the same buffer allocation in eal_interrupts.c.

The third patch removes the no_wvla_cflag workaround from meson.build
now that the VLAs have been eliminated.

Stephen Hemminger (3):
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings

 drivers/common/cnxk/meson.build    | 2 --
 drivers/common/cnxk/roc_aes.c      | 3 ++-
 drivers/common/cnxk/roc_platform.c | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

-- 
2.51.0

[PATCH v2 1/3] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..b42c785249 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	RTE_ASSERT(in_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

[PATCH v2 2/3] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

[PATCH v2 3/3] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLAs.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index daffc15afd..58ebf4c99f 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,8 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
-
 if meson.is_cross_build()
     soc_type = meson.get_external_property('platform', '')
 else
-- 
2.51.0

[PATCH v3 0/6] fix GCC warnings when building with LTO

[Stephen Hemminger]

This series fixes all warnings produced by GCC when building DPDK with
Link Time Optimization (LTO) enabled. LTO performs aggressive cross-
compilation-unit inlining and interprocedural analysis, which exposes
issues that are not visible during normal compilation.

The problems were diagnosed using AI but the fixes all look
very reasonable and consistent with other code.

The fixes fall into three categories:

1. Buffer sizing for static analysis (patches 1, 6)

   When LTO inlines functions across compilation units, GCC's static
   analyzer gains visibility into buffer sizes and all code paths.
   This causes warnings when the analyzer cannot prove that runtime-
   selected code paths stay within buffer bounds. The fixes provide
   either larger buffers or explicit bounds checks to satisfy the
   analyzer.

2. Variable Length Array (VLA) elimination (patches 2, 3, 4)

   VLAs cause -Wvla-larger-than warnings with LTO because the compiler
   cannot determine array bounds at compile time. These patches replace
   VLAs with fixed-size arrays using existing defines, then remove the
   warning suppression flag that was masking the issue.

3. Genuine bug fix (patch 5)

   The LTO analysis uncovered an actual buffer overflow bug where a
   1-byte allocation was being used for an 808-byte structure. This
   is a real memory corruption issue, not just a false positive.

The patches have been tested with GCC 14 using -flto=auto and produce
a clean build with no warnings.

v3 - add all the other stuff necessary to fix all the LTO warnings

Stephen Hemminger (6):
  test/soring: fix buffer overflow warnings with LTO
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings
  common/cnxk: fix buffer overflow in reassembly SA setup
  net/mlx5/hws: fix LTO false positive stringop-overflow warning

 app/test/test_soring.c               | 29 +++++++++++++++++++++-------
 drivers/common/cnxk/meson.build      |  2 --
 drivers/common/cnxk/roc_aes.c        |  3 ++-
 drivers/common/cnxk/roc_nix_inl.c    |  2 +-
 drivers/common/cnxk/roc_platform.c   |  4 ++--
 drivers/net/mlx5/hws/mlx5dr_action.c | 14 ++++++++++++++
 6 files changed, 41 insertions(+), 13 deletions(-)

-- 
2.51.0

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

[Stephen Hemminger]

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.

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

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

[Morten Brørup]

> 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

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

[Stephen Hemminger]

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 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. Since there is no good
way other than turning of LTO for the test to tell the compiler

> 
> 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.

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

[Morten Brørup]

> 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()

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

The soring functions are inline, so adding __rte_assume(sor->esize == sizeof(uint32_t)) before calling them tells the compiler that only the code path for 4 byte element size is relevant, so the compiler can eliminate the code paths for other element sizes.

Using __rte_assume() has worked for me in other cases, not just for optimization purposes, but also when the compiler gets confused about potential buffer overruns (that we know cannot occur, i.e. false positives).

It might solve this problem too.
IMO, it is generally preferable to help the compiler (by providing hints) rather than implementing workarounds (using oversized buffers in this case).

> >
> > 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.

Re: [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@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.

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

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 20 January 2026 15.34
> 
> 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.

Does this fix generally imply that when using LTO, using an SORING with elements smaller than 16 bytes requires oversize buffers?
That's not good. :-(

The SORING is still experimental.
Maybe the element size and metadata size need to be passed as parameters to the SORING functions, like the RING functions take element size as parameter (except the functions that are hardcoded for using pointers as element size).

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

[Konstantin Ananyev]

> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Tuesday, 20 January 2026 15.34
> >
> > 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.
> 
> Does this fix generally imply that when using LTO, using an SORING with elements
> smaller than 16 bytes requires oversize buffers?
> That's not good. :-(
> 
> The SORING is still experimental.
> Maybe the element size and metadata size need to be passed as parameters to
> the SORING functions, like the RING functions take element size as parameter
> (except the functions that are hardcoded for using pointers as element size).

Personally, I am not a big fan of such idea...
Wonder is that possible just to disable LTO for soring.o?
Another thought - if all the problems come from 128 bit version of enque/dequeue,
would using memcpy() instead  of specific functions help to mitigate the problem?  

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

[Stephen Hemminger]

On Tue, 20 Jan 2026 15:40:21 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Tuesday, 20 January 2026 15.34
> > >
> > > 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.  
> > 
> > Does this fix generally imply that when using LTO, using an SORING with elements
> > smaller than 16 bytes requires oversize buffers?
> > That's not good. :-(
> > 
> > The SORING is still experimental.
> > Maybe the element size and metadata size need to be passed as parameters to
> > the SORING functions, like the RING functions take element size as parameter
> > (except the functions that are hardcoded for using pointers as element size).  
> 
> Personally, I am not a big fan of such idea...
> Wonder is that possible just to disable LTO for soring.o?
> Another thought - if all the problems come from 128 bit version of enque/dequeue,
> would using memcpy() instead  of specific functions help to mitigate the problem?  
> 
> 

Not sure if disabling for single file works.

My goal is just to make LTO build work without any warnings.
LTO has proved useful in finding bugs where arrays are overwritten.

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

[Stephen Hemminger]

On Tue, 20 Jan 2026 15:40:21 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Tuesday, 20 January 2026 15.34
> > >
> > > 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.  
> > 
> > Does this fix generally imply that when using LTO, using an SORING with elements
> > smaller than 16 bytes requires oversize buffers?
> > That's not good. :-(
> > 
> > The SORING is still experimental.
> > Maybe the element size and metadata size need to be passed as parameters to
> > the SORING functions, like the RING functions take element size as parameter
> > (except the functions that are hardcoded for using pointers as element size).  
> 
> Personally, I am not a big fan of such idea...
> Wonder is that possible just to disable LTO for soring.o?
> Another thought - if all the problems come from 128 bit version of enque/dequeue,
> would using memcpy() instead  of specific functions help to mitigate the problem?  
> 
> 

I did some more experiments using pragmas, and attributes.
The good news is it works for some versions of Gcc,
the bad news is that pragmas and optimization changes on function basis
seem to crash old compilers, and be disabled in Gcc 16 and get:

../app/test/test_soring.c:154:1: warning: bad option ‘-fno-lto’ to attribute ‘optimize’ [-Wattributes]

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

[Stephen Hemminger]

On Tue, 20 Jan 2026 15:40:21 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Tuesday, 20 January 2026 15.34
> > >
> > > 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.  
> > 
> > Does this fix generally imply that when using LTO, using an SORING with elements
> > smaller than 16 bytes requires oversize buffers?
> > That's not good. :-(
> > 
> > The SORING is still experimental.
> > Maybe the element size and metadata size need to be passed as parameters to
> > the SORING functions, like the RING functions take element size as parameter
> > (except the functions that are hardcoded for using pointers as element size).  
> 
> Personally, I am not a big fan of such idea...
> Wonder is that possible just to disable LTO for soring.o?
> Another thought - if all the problems come from 128 bit version of enque/dequeue,
> would using memcpy() instead  of specific functions help to mitigate the problem?  
> 
> 

A much simpler and clear solution is to just get rid of __rte_always_inline
and use inline instead. The compiler still inlines a lot but it can make its
own decision.

The attribute always_inline is not always faster, in fact in real world
applications it can make things slower because real applications get i-cache
misses and lots of inline expansion makes it worse.

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

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 20 January 2026 20.27
> 
> On Tue, 20 Jan 2026 15:40:21 +0000
> Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:
> 
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Tuesday, 20 January 2026 15.34
> > > >
> > > > 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.
> > >
> > > Does this fix generally imply that when using LTO, using an SORING
> with elements
> > > smaller than 16 bytes requires oversize buffers?
> > > That's not good. :-(
> > >
> > > The SORING is still experimental.
> > > Maybe the element size and metadata size need to be passed as
> parameters to
> > > the SORING functions, like the RING functions take element size as
> parameter
> > > (except the functions that are hardcoded for using pointers as
> element size).
> >
> > Personally, I am not a big fan of such idea...
> > Wonder is that possible just to disable LTO for soring.o?
> > Another thought - if all the problems come from 128 bit version of
> enque/dequeue,
> > would using memcpy() instead  of specific functions help to mitigate
> the problem?
> >
> >
> 
> A much simpler and clear solution is to just get rid of
> __rte_always_inline
> and use inline instead. The compiler still inlines a lot but it can
> make its
> own decision.
> 
> The attribute always_inline is not always faster, in fact in real world
> applications it can make things slower because real applications get i-
> cache
> misses and lots of inline expansion makes it worse.

Here's another (untested) idea...

Maybe it would help moving the inlining around.
The SORING way of inlining differs from the RING way of inlining.

In RING inlining starts at the outermost layer.

*rte_ring.h:*
static __rte_always_inline unsigned int
rte_ring_dequeue_bulk(struct rte_ring *r, void **obj_table, unsigned int n,
		unsigned int *available)
{
	return rte_ring_dequeue_bulk_elem(r, obj_table, sizeof(void *),
			n, available);

In SORING, the outermost layer is a normal function.

*rte_soring.h:*
__rte_experimental
uint32_t
rte_soring_dequeue_bulk(struct rte_soring *r, void *objs,
	uint32_t num, uint32_t *available);

*soring.c:*
RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_soring_dequeue_bulk, 25.03)
uint32_t
rte_soring_dequeue_bulk(struct rte_soring *r, void *objs, uint32_t num,
	uint32_t *available)
{
	return soring_dequeue(r, objs, NULL, num, RTE_RING_QUEUE_FIXED,
			available);
}

Note that for RING, the element size is determined at the outermost layer and passed as a parameter to the underlying functions.

I'm not sure that modifying SORING to the same style of inlining solves anything. The element size is build time constant for RING, but SORING would have to pass r->esize as element size parameter, and that is not build time constant.
With such a change, my suggestion of adding __rte_assume(r->esize == sizeof(uint32_t)) at the application might work.
In my experience, __rte_assume() needs to be very close to the code using it, or it has no effect.

It would be an ABI change, but not an API change.

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

[Konstantin Ananyev]

> On Tue, 20 Jan 2026 15:40:21 +0000
> Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:
> 
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Tuesday, 20 January 2026 15.34
> > > >
> > > > 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.
> > >
> > > Does this fix generally imply that when using LTO, using an SORING with
> elements
> > > smaller than 16 bytes requires oversize buffers?
> > > That's not good. :-(
> > >
> > > The SORING is still experimental.
> > > Maybe the element size and metadata size need to be passed as parameters
> to
> > > the SORING functions, like the RING functions take element size as
> parameter
> > > (except the functions that are hardcoded for using pointers as element size).
> >
> > Personally, I am not a big fan of such idea...
> > Wonder is that possible just to disable LTO for soring.o?
> > Another thought - if all the problems come from 128 bit version of
> enque/dequeue,
> > would using memcpy() instead  of specific functions help to mitigate the
> problem?
> >
> >
> 
> A much simpler and clear solution is to just get rid of __rte_always_inline
> and use inline instead. The compiler still inlines a lot but it can make its
> own decision.
> The attribute always_inline is not always faster, in fact in real world
> applications it can make things slower because real applications get i-cache
> misses and lots of inline expansion makes it worse.

Sounds like a clean and safe fix.
I also don't expect any perf degradations with such approach, 
but will run some perf tests with it to confirm.
Thanks

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

[Stephen Hemminger]

On Wed, 21 Jan 2026 12:56:25 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> > A much simpler and clear solution is to just get rid of __rte_always_inline
> > and use inline instead. The compiler still inlines a lot but it can make its
> > own decision.
> > The attribute always_inline is not always faster, in fact in real world
> > applications it can make things slower because real applications get i-cache
> > misses and lots of inline expansion makes it worse.  
> 
> Sounds like a clean and safe fix.
> I also don't expect any perf degradations with such approach, 
> but will run some perf tests with it to confirm.
> Thanks

Only enqueue/dequeue functions needed the change.

[PATCH v3 2/6] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..b42c785249 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	RTE_ASSERT(in_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

[PATCH v3 3/6] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

[PATCH v3 4/6] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLAs.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index daffc15afd..58ebf4c99f 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,8 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
-
 if meson.is_cross_build()
     soc_type = meson.get_external_property('platform', '')
 else
-- 
2.51.0

[PATCH v3 5/6] common/cnxk: fix buffer overflow in reassembly SA setup

[Stephen Hemminger]

The nix_inl_reass_inb_sa_tbl_setup() function initializes inb_sa_sz
to 1 byte, then allocates a buffer of that size. However, the buffer
is subsequently passed to roc_ow_reass_inb_sa_init() which performs:

    memset(sa, 0, sizeof(struct roc_ow_ipsec_inb_sa));

This writes 808 bytes into a 1-byte allocation, causing heap corruption.

This bug was detected by GCC's -Wstringop-overflow warning when
building with LTO, which enables cross-compilation-unit inlining
and allows the compiler to track the allocation size through to
the memset call.

Fix by initializing inb_sa_sz to ROC_NIX_INL_OW_IPSEC_INB_SA_SZ,
which is the standard macro used elsewhere in this file for OW
(Sobek) inbound SA allocations.

Fixes: 75e073242acb ("common/cnxk: support reassembly with inline IPsec")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_nix_inl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_inl.c b/drivers/common/cnxk/roc_nix_inl.c
index f8be98efd5..1766f68c17 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -583,7 +583,7 @@ nix_inl_reass_inb_sa_tbl_setup(struct roc_nix *roc_nix)
 	uint64_t sa_idx_w, lenm1_max;
 	uint64_t res_addr_offset = 0;
 	uint64_t def_cptq = 0;
-	size_t inb_sa_sz = 1;
+	size_t inb_sa_sz = ROC_NIX_INL_OW_IPSEC_INB_SA_SZ;
 	uint8_t profile_id;
 	struct mbox *mbox;
 	void *sa;
-- 
2.51.0

[PATCH v3 6/6] net/mlx5/hws: fix LTO false positive stringop-overflow warning

[Stephen Hemminger]

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.

Signed-off-by: Stephen Hemminger <stephen@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;
+
 	/* 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

[PATCH v4 0/6] fix build failures with LTO enabled

[Stephen Hemminger]

This series addresses build failures and warnings that occur when
compiling DPDK with Link Time Optimization (LTO) enabled. LTO performs
aggressive cross-compilation-unit inlining, which allows GCC's static
analyzer to detect both real bugs and generate false positive warnings
that are not visible without LTO.

The series fixes:
- Real bugs: buffer overflow in cnxk reassembly SA setup (heap corruption)
- Variable-length arrays that trigger warnings with LTO
- False positive warnings where compiler cannot prove bounds safety

v4
  - add Fixes tags where appropriate
  - Bugzilla ID's for existing bugs

The cnxk patches (1-4) should be applied together as they eliminate
all VLAs from common/cnxk and re-enable VLA warnings. The remaining
patches (5-6) address warnings in other subsystems.

Stephen Hemminger (6):
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings
  common/cnxk: fix buffer overflow in reassembly SA setup
  net/mlx5: fix LTO false positive stringop-overflow warning
  test/soring: fix stringop-overflow warning with LTO

 app/test/test_soring.c               | 18 ++++++++++++------
 drivers/common/cnxk/meson.build      |  2 --
 drivers/common/cnxk/roc_aes.c        |  3 ++-
 drivers/common/cnxk/roc_nix_inl.c    |  2 +-
 drivers/common/cnxk/roc_platform.c   |  4 ++--
 drivers/net/mlx5/hws/mlx5dr_action.c | 14 ++++++++++++++
 6 files changed, 31 insertions(+), 12 deletions(-)

-- 
2.51.0

[PATCH v4 1/6] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..babf149ccf 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	PLT_ASSERT(in_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

[PATCH v4 2/6] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Bugzilla ID: 1863
Fixes: 375cb1601882 ("common/cnxk: move interrupt handling to platform-specific")
Cc: skoteshwar@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

[PATCH v4 3/6] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLAs.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index daffc15afd..58ebf4c99f 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,8 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
-
 if meson.is_cross_build()
     soc_type = meson.get_external_property('platform', '')
 else
-- 
2.51.0

[PATCH v4 4/6] common/cnxk: fix buffer overflow in reassembly SA setup

[Stephen Hemminger]

The nix_inl_reass_inb_sa_tbl_setup() function initializes inb_sa_sz
to 1 byte, then allocates a buffer of that size. However, the buffer
is subsequently passed to roc_ow_reass_inb_sa_init() which performs:

    memset(sa, 0, sizeof(struct roc_ow_ipsec_inb_sa));

This writes 808 bytes into a 1-byte allocation, causing heap corruption.

This bug was detected by GCC's -Wstringop-overflow warning when
building with LTO, which enables cross-compilation-unit inlining
and allows the compiler to track the allocation size through to
the memset call.

Fix by initializing inb_sa_sz to ROC_NIX_INL_OW_IPSEC_INB_SA_SZ,
which is the standard macro used elsewhere in this file for OW
(Sobek) inbound SA allocations.

Bugzilla ID: 1513
Fixes: fc9a711b5c8f ("common/cnxk: add NIX inline reassembly profile config")
Cc: rbhansali@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_nix_inl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_inl.c b/drivers/common/cnxk/roc_nix_inl.c
index f8be98efd5..1766f68c17 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -583,7 +583,7 @@ nix_inl_reass_inb_sa_tbl_setup(struct roc_nix *roc_nix)
 	uint64_t sa_idx_w, lenm1_max;
 	uint64_t res_addr_offset = 0;
 	uint64_t def_cptq = 0;
-	size_t inb_sa_sz = 1;
+	size_t inb_sa_sz = ROC_NIX_INL_OW_IPSEC_INB_SA_SZ;
 	uint8_t profile_id;
 	struct mbox *mbox;
 	void *sa;
-- 
2.51.0

[PATCH v4 5/6] net/mlx5: fix LTO false positive stringop-overflow warning

[Stephen Hemminger]

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@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@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;
+
 	/* 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

[PATCH v4 6/6] test/soring: fix stringop-overflow warning with LTO

[Stephen Hemminger]

When LTO is enabled, GCC inlines through the soring dequeue path into
__rte_ring_dequeue_elems_128(), which copies 32 bytes per element for
128-bit ring elements. The compiler cannot prove at compile time that
this code path is unreachable when elem_size is 4 bytes, resulting in
warnings like:

  warning: writing 32 bytes into a region of size 0 [-Wstringop-overflow=]
  note: at offset 128 into destination object 'dequeued_objs' of size 128

The test allocates uint32_t arrays of 32 elements (128 bytes), which is
correct for 32 elements of 4 bytes each. However, the 128-bit path
would require 512 bytes for 32 elements.

Using __rte_assume or RTE_ASSERT in this case is not enough to
resolve the problem because the condition does not propogate
through the compiler inlining so the compiler still can't
prove the 128-bit path won't be taken.

Increase the array sizes in test_soring_stages() to 128 uint32_t
elements (512 bytes) to accommodate the worst-case 128-bit element
path that the compiler cannot eliminate.

Bugzilla ID: 1726
Fixes: 70581c355d69 ("test/ring: add unit tests for soring API")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 app/test/test_soring.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/app/test/test_soring.c b/app/test/test_soring.c
index 52852692d4..9e8e1e5fae 100644
--- a/app/test/test_soring.c
+++ b/app/test/test_soring.c
@@ -149,12 +149,18 @@ 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];
+	/*
+	 * The soring/ring code has paths for 4/8/16-byte elements.
+	 * With LTO, GCC cannot eliminate the 16-byte path and warns
+	 * about potential buffer overflow. Size arrays for worst case:
+	 * 32 elements * 16 bytes = 512 bytes = 128 uint32_t.
+	 */
+	uint32_t objs[128];
+	uint32_t rcs[128];
+	uint32_t acquired_objs[128];
+	uint32_t acquired_rcs[128];
+	uint32_t dequeued_rcs[128];
+	uint32_t dequeued_objs[128];
 	size_t ssz;
 	uint32_t stage, enqueued, dequeued, acquired;
 	uint32_t i, ftoken;
-- 
2.51.0

[PATCH 0/6] Fix LTO compilation warnings

[Stephen Hemminger]

TLDR; fixes LTO build

Full explaination from AI...
This patch series addresses multiple compilation warnings and one buffer
overflow bug that are revealed when with Link Time Optimization (LTO)
enabled.

LTO enables cross-compilation-unit analysis and inlining, which allows
GCC to detect issues that would otherwise be hidden. The patches fall
into three categories:

1. Variable Length Array (VLA) fixes in common/cnxk [patches 1-3]
   - Replace VLAs with fixed-size arrays and appropriate bounds checking
   - Re-enable VLA warnings after fixes are complete

2. Actual bug fix in common/cnxk [patch 4]
   - Fixes buffer overflow in IPsec inbound SA initialization
   - Detected by GCC's -Wstringop-overflow with LTO enabled

3. False positive warning fixes [patches 5-6]
   - Add explicit bounds checks to help GCC's static analysis
   - Adjust inline attributes to prevent spurious warnings

All patches have been tested with LTO enabled and resolve the respective
compilation warnings.

Stephen Hemminger (6):
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings
  common/cnxk: fix buffer overflow in SA setup
  net/mlx5: fix LTO stringop-overflow warning
  ring: use inline instead of always inline in soring

 drivers/common/cnxk/meson.build      |  1 -
 drivers/common/cnxk/roc_aes.c        |  3 ++-
 drivers/common/cnxk/roc_nix_inl.c    |  2 +-
 drivers/common/cnxk/roc_platform.c   |  4 ++--
 drivers/net/mlx5/hws/mlx5dr_action.c | 14 ++++++++++++++
 lib/ring/soring.c                    |  4 ++--
 6 files changed, 21 insertions(+), 7 deletions(-)

-- 
2.51.0

[PATCH v5 1/6] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..babf149ccf 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	PLT_ASSERT(in_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

[PATCH v5 2/6] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Bugzilla ID: 1863
Fixes: 375cb1601882 ("common/cnxk: move interrupt handling to platform-specific")
Cc: skoteshwar@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

[PATCH v5 3/6] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLAs.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index 2b33022eb7..9db77a9702 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,7 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
 cflags += no_shadow_cflag
 
 if meson.is_cross_build()
-- 
2.51.0

[PATCH v5 4/6] common/cnxk: fix buffer overflow in SA setup

[Stephen Hemminger]

The nix_inl_reass_inb_sa_tbl_setup() function initializes inb_sa_sz
to 1 byte, then allocates a buffer of that size. However, the buffer
is subsequently passed to roc_ow_reass_inb_sa_init() which performs:

    memset(sa, 0, sizeof(struct roc_ow_ipsec_inb_sa));

This writes 808 bytes into a 1-byte allocation, causing heap corruption.

This bug was detected by GCC's -Wstringop-overflow warning when
building with LTO, which enables cross-compilation-unit inlining
and allows the compiler to track the allocation size through to
the memset call.

Fix by initializing inb_sa_sz to ROC_NIX_INL_OW_IPSEC_INB_SA_SZ,
which is the standard macro used elsewhere in this file for OW
(Sobek) inbound SA allocations.

Bugzilla ID: 1513
Fixes: fc9a711b5c8f ("common/cnxk: add NIX inline reassembly profile config")
Cc: rbhansali@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_nix_inl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_inl.c b/drivers/common/cnxk/roc_nix_inl.c
index f8be98efd5..1766f68c17 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -583,7 +583,7 @@ nix_inl_reass_inb_sa_tbl_setup(struct roc_nix *roc_nix)
 	uint64_t sa_idx_w, lenm1_max;
 	uint64_t res_addr_offset = 0;
 	uint64_t def_cptq = 0;
-	size_t inb_sa_sz = 1;
+	size_t inb_sa_sz = ROC_NIX_INL_OW_IPSEC_INB_SA_SZ;
 	uint8_t profile_id;
 	struct mbox *mbox;
 	void *sa;
-- 
2.51.0

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

[Stephen Hemminger]

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@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@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;
+
 	/* 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

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

[Dariusz Sosnowski]

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@dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen@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
> 

Re: [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@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@dpdk.org
> > 
> > Signed-off-by: Stephen Hemminger <stephen@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

[PATCH v5 6/6] ring: use inline instead of always inline in soring

[Stephen Hemminger]

When LTO is enabled, GCC inlines through the entire soring call chain
from test code into the ring element copy functions. With always_inline,
the compiler is forced to inline __rte_ring_dequeue_elems_128() which
copies 32 bytes per element. GCC's static analysis then warns about
potential buffer overflow because it cannot prove the 128-bit element
path is unreachable when the ring is configured for 4-byte elements:

  warning: writing 32 bytes into a region of size 0 [-Wstringop-overflow=]

By using plain inline instead of always_inline on the soring enqueue
and dequeue functions, the compiler regains discretion over inlining
decisions. This introduces an analysis boundary that prevents GCC from
connecting the test's buffer sizes to the unreachable 128-bit code path,
eliminating the false positive warning.

Performance impact is expected to be negligible. At -O2/-O3, the
compiler will still inline these small, hot functions based on its
own heuristics. The difference only matters in debug builds or with
-Os, where slightly less aggressive inlining is acceptable.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 lib/ring/soring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/ring/soring.c b/lib/ring/soring.c
index 797484d6bf..3b90521bdb 100644
--- a/lib/ring/soring.c
+++ b/lib/ring/soring.c
@@ -249,7 +249,7 @@ __rte_soring_stage_move_head(struct soring_stage_headtail *d,
 	return n;
 }
 
-static __rte_always_inline uint32_t
+static inline uint32_t
 soring_enqueue(struct rte_soring *r, const void *objs,
 	const void *meta, uint32_t n, enum rte_ring_queue_behavior behavior,
 	uint32_t *free_space)
@@ -278,7 +278,7 @@ soring_enqueue(struct rte_soring *r, const void *objs,
 	return n;
 }
 
-static __rte_always_inline uint32_t
+static inline uint32_t
 soring_dequeue(struct rte_soring *r, void *objs, void *meta,
 	uint32_t num, enum rte_ring_queue_behavior behavior,
 	uint32_t *available)
-- 
2.51.0

RE: [PATCH v5 6/6] ring: use inline instead of always inline in soring

[Konstantin Ananyev]

> 
> When LTO is enabled, GCC inlines through the entire soring call chain
> from test code into the ring element copy functions. With always_inline,
> the compiler is forced to inline __rte_ring_dequeue_elems_128() which
> copies 32 bytes per element. GCC's static analysis then warns about
> potential buffer overflow because it cannot prove the 128-bit element
> path is unreachable when the ring is configured for 4-byte elements:
> 
>   warning: writing 32 bytes into a region of size 0 [-Wstringop-overflow=]
> 
> By using plain inline instead of always_inline on the soring enqueue
> and dequeue functions, the compiler regains discretion over inlining
> decisions. This introduces an analysis boundary that prevents GCC from
> connecting the test's buffer sizes to the unreachable 128-bit code path,
> eliminating the false positive warning.
> 
> Performance impact is expected to be negligible. At -O2/-O3, the
> compiler will still inline these small, hot functions based on its
> own heuristics. The difference only matters in debug builds or with
> -Os, where slightly less aggressive inlining is acceptable.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  lib/ring/soring.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/ring/soring.c b/lib/ring/soring.c
> index 797484d6bf..3b90521bdb 100644
> --- a/lib/ring/soring.c
> +++ b/lib/ring/soring.c
> @@ -249,7 +249,7 @@ __rte_soring_stage_move_head(struct
> soring_stage_headtail *d,
>  	return n;
>  }
> 
> -static __rte_always_inline uint32_t
> +static inline uint32_t
>  soring_enqueue(struct rte_soring *r, const void *objs,
>  	const void *meta, uint32_t n, enum rte_ring_queue_behavior behavior,
>  	uint32_t *free_space)
> @@ -278,7 +278,7 @@ soring_enqueue(struct rte_soring *r, const void *objs,
>  	return n;
>  }
> 
> -static __rte_always_inline uint32_t
> +static inline uint32_t
>  soring_dequeue(struct rte_soring *r, void *objs, void *meta,
>  	uint32_t num, enum rte_ring_queue_behavior behavior,
>  	uint32_t *available)
> --

Run quick test, no perf degradation noticed.
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Tested-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
 
> 2.51.0

RE: [PATCH v5 6/6] ring: use inline instead of always inline in soring

[Morten Brørup]

> > When LTO is enabled, GCC inlines through the entire soring call chain
> > from test code into the ring element copy functions. With
> always_inline,
> > the compiler is forced to inline __rte_ring_dequeue_elems_128() which
> > copies 32 bytes per element. GCC's static analysis then warns about
> > potential buffer overflow because it cannot prove the 128-bit element
> > path is unreachable when the ring is configured for 4-byte elements:
> >
> >   warning: writing 32 bytes into a region of size 0 [-Wstringop-
> overflow=]
> >
> > By using plain inline instead of always_inline on the soring enqueue
> > and dequeue functions, the compiler regains discretion over inlining
> > decisions. This introduces an analysis boundary that prevents GCC
> from
> > connecting the test's buffer sizes to the unreachable 128-bit code
> path,
> > eliminating the false positive warning.
> >
> > Performance impact is expected to be negligible. At -O2/-O3, the
> > compiler will still inline these small, hot functions based on its
> > own heuristics. The difference only matters in debug builds or with
> > -Os, where slightly less aggressive inlining is acceptable.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> >  lib/ring/soring.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/ring/soring.c b/lib/ring/soring.c
> > index 797484d6bf..3b90521bdb 100644
> > --- a/lib/ring/soring.c
> > +++ b/lib/ring/soring.c
> > @@ -249,7 +249,7 @@ __rte_soring_stage_move_head(struct
> > soring_stage_headtail *d,
> >  	return n;
> >  }
> >
> > -static __rte_always_inline uint32_t
> > +static inline uint32_t
> >  soring_enqueue(struct rte_soring *r, const void *objs,
> >  	const void *meta, uint32_t n, enum rte_ring_queue_behavior
> behavior,
> >  	uint32_t *free_space)
> > @@ -278,7 +278,7 @@ soring_enqueue(struct rte_soring *r, const void
> *objs,
> >  	return n;
> >  }
> >
> > -static __rte_always_inline uint32_t
> > +static inline uint32_t
> >  soring_dequeue(struct rte_soring *r, void *objs, void *meta,
> >  	uint32_t num, enum rte_ring_queue_behavior behavior,
> >  	uint32_t *available)
> > --
> 
> Run quick test, no perf degradation noticed.
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> Tested-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>

We want LTO to work, and the alternatives discussed in another thread [1] are not popular.
Acked-by: Morten Brørup <mb@smartsharesystems.com>

[1]: https://inbox.dpdk.org/dev/20260116064646.224254-2-stephen@networkplumber.org/

[PATCH v6 0/6] Fix LTO compilation warnings

[Stephen Hemminger]

This series fixes compilation warnings and one buffer overflow bug
exposed when building DPDK with Link Time Optimization (LTO) enabled.

v6:
  - net/mlx5: use __rte_assume() instead of runtime bounds check
    per Dariusz Sosnowski's review, avoiding any overhead on the
    flow creation fast path

Stephen Hemminger (6):
  common/cnxk: replace variable length state array
  common/cnxk: replace variable length array
  common/cnxk: re-enable vla warnings
  common/cnxk: fix buffer overflow in SA setup
  ring: use inline instead of always inline in soring
  net/mlx5: fix LTO stringop-overflow warning

 drivers/common/cnxk/meson.build      |  1 -
 drivers/common/cnxk/roc_aes.c        |  3 ++-
 drivers/common/cnxk/roc_nix_inl.c    |  2 +-
 drivers/common/cnxk/roc_platform.c   |  4 ++--
 drivers/net/mlx5/hws/mlx5dr_action.c | 11 +++++++++++
 lib/ring/soring.c                    |  4 ++--
 6 files changed, 18 insertions(+), 7 deletions(-)

-- 
2.51.0

[PATCH v6 1/6] common/cnxk: replace variable length state array

[Stephen Hemminger]

The cipher function is always called with in_len = 16
and there is an existing define for that.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
index d84feb546a..babf149ccf 100644
--- a/drivers/common/cnxk/roc_aes.c
+++ b/drivers/common/cnxk/roc_aes.c
@@ -157,9 +157,10 @@ static void
 cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t in_len)
 {
 	uint8_t data_word_len = in_len / sizeof(uint32_t);
-	uint32_t state[data_word_len];
+	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
 	unsigned int i, round;
 
+	PLT_ASSERT(in_len <= AES_HASH_KEY_LEN);
 	memcpy(state, in, sizeof(state));
 
 	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
-- 
2.51.0

RE: [EXTERNAL] [PATCH v6 1/6] common/cnxk: replace variable length state array

[Tejasree Kondoj]

Hi Stephen,

Minor nit inline. With that

Acked-by: Tejasree Kondoj <ktejasree@marvell.com>

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, February 5, 2026 11:26 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger <stephen@networkplumber.org>; Nithin Kumar
> Dabilpuram <ndabilpuram@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Sunil Kumar Kori <skori@marvell.com>; Satha
> Koteswara Rao Kottidi <skoteshwar@marvell.com>; Harman Kalra
> <hkalra@marvell.com>
> Subject: [EXTERNAL] [PATCH v6 1/6] common/cnxk: replace variable length
> state array
> 
> The cipher function is always called with in_len = 16
> and there is an existing define for that.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  drivers/common/cnxk/roc_aes.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
> index d84feb546a..babf149ccf 100644
> --- a/drivers/common/cnxk/roc_aes.c
> +++ b/drivers/common/cnxk/roc_aes.c
> @@ -157,9 +157,10 @@ static void
>  cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t
> in_len)
>  {
>  	uint8_t data_word_len = in_len / sizeof(uint32_t);
> -	uint32_t state[data_word_len];
> +	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];
[Tejasree] This line needs to be moved up to maintain reverse xmas tree.

>  	unsigned int i, round;
> 
> +	PLT_ASSERT(in_len <= AES_HASH_KEY_LEN);
>  	memcpy(state, in, sizeof(state));
> 
>  	/* AddRoundKey(state, w[0, Nb-1]) // See Sec. 5.1.4 */
> --
> 2.51.0

Re: [EXTERNAL] [PATCH v6 1/6] common/cnxk: replace variable length state array

[Stephen Hemminger]

On Mon, 2 Mar 2026 19:06:19 +0000
Tejasree Kondoj <ktejasree@marvell.com> wrote:

> > diff --git a/drivers/common/cnxk/roc_aes.c b/drivers/common/cnxk/roc_aes.c
> > index d84feb546a..babf149ccf 100644
> > --- a/drivers/common/cnxk/roc_aes.c
> > +++ b/drivers/common/cnxk/roc_aes.c
> > @@ -157,9 +157,10 @@ static void
> >  cipher(uint8_t *in, uint8_t *out, uint32_t *ks, uint32_t key_rounds, uint8_t
> > in_len)
> >  {
> >  	uint8_t data_word_len = in_len / sizeof(uint32_t);
> > -	uint32_t state[data_word_len];
> > +	uint32_t state[AES_HASH_KEY_LEN / sizeof(uint32_t)];  
> [Tejasree] This line needs to be moved up to maintain reverse xmas tree.

That is a Linux netdev thing, DPDK doesn't care about that.

[PATCH v6 2/6] common/cnxk: replace variable length array

[Stephen Hemminger]

This fixes errors when compiled with LTO about large VLA.
../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:
../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
      |              ^

Since the number of IRQ is limited by EAL max interrupt vectors
use that define that already exists rather than a function call
hidden in a macro.

Bugzilla ID: 1863
Fixes: 375cb1601882 ("common/cnxk: move interrupt handling to platform-specific")
Cc: skoteshwar@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c
index e13cb42285..1fdbf8f051 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -17,8 +17,8 @@
 #include <sys/ioctl.h>
 #include <unistd.h>
 
-#define MSIX_IRQ_SET_BUF_LEN                                                                       \
-	(sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))
+#define MSIX_IRQ_SET_BUF_LEN							\
+	(sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)
 
 static int
 irq_get_info(struct plt_intr_handle *intr_handle)
-- 
2.51.0

RE: [EXTERNAL] [PATCH v6 2/6] common/cnxk: replace variable length array

[Tejasree Kondoj]

[-- Attachment #1: Type: text/plain, Size: 2904 bytes --]

Acked-by: Tejasree Kondoj <ktejasree@marvell.com>

From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Thursday, February 5, 2026 11:26 PM
To: dev@dpdk.org
Cc: Stephen Hemminger <stephen@networkplumber.org>; Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>; stable@dpdk.org; Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>; Sunil Kumar Kori <skori@marvell.com>; Harman Kalra <hkalra@marvell.com>
Subject: [EXTERNAL] [PATCH v6 2/6] common/cnxk: replace variable length array

This fixes errors when compiled with LTO about large VLA. .. /drivers/common/cnxk/roc_platform. c: In function ‘irq_init’: .. /drivers/common/cnxk/roc_platform. c: 92: 14: warning: argument to variable-length array is too large [-Wvla-larger-than=]
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!tq3Z1f8UYnWa9K-cWX26ztpYTgkipucwksIFWb6OAmEPh_V3Ac4-BrjxCsV7Xh7swUxc2cswohoNMT7ip8nHpaVjKY9y6l7leDPcyhU$>   ‌
ZjQcmQRYFpfptBannerEnd

This fixes errors when compiled with LTO about large VLA.

../drivers/common/cnxk/roc_platform.c: In function ‘irq_init’:

../drivers/common/cnxk/roc_platform.c:92:14: warning: argument to variable-length array is too large [-Wvla-larger-than=]

   92 |         char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];

      |              ^



Since the number of IRQ is limited by EAL max interrupt vectors

use that define that already exists rather than a function call

hidden in a macro.



Bugzilla ID: 1863

Fixes: 375cb1601882 ("common/cnxk: move interrupt handling to platform-specific")

Cc: skoteshwar@marvell.com<mailto:skoteshwar@marvell.com>

Cc: stable@dpdk.org<mailto:stable@dpdk.org>



Signed-off-by: Stephen Hemminger <stephen@networkplumber.org<mailto:stephen@networkplumber.org>>

---

 drivers/common/cnxk/roc_platform.c | 4 ++--

 1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/drivers/common/cnxk/roc_platform.c b/drivers/common/cnxk/roc_platform.c

index e13cb42285..1fdbf8f051 100644

--- a/drivers/common/cnxk/roc_platform.c

+++ b/drivers/common/cnxk/roc_platform.c

@@ -17,8 +17,8 @@

 #include <sys/ioctl.h>

 #include <unistd.h>



-#define MSIX_IRQ_SET_BUF_LEN                                                                       \

-          (sizeof(struct vfio_irq_set) + sizeof(int) * (plt_intr_max_intr_get(intr_handle)))

+#define MSIX_IRQ_SET_BUF_LEN                                                                                     \

+          (sizeof(struct vfio_irq_set) + sizeof(int) * PLT_MAX_RXTX_INTR_VEC_ID)



 static int

 irq_get_info(struct plt_intr_handle *intr_handle)

--

2.51.0



[-- Attachment #2: Type: text/html, Size: 13013 bytes --]

[PATCH v6 3/6] common/cnxk: re-enable vla warnings

[Stephen Hemminger]

The code in common/cnxk no longer uses VLAs.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/meson.build | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index 2b33022eb7..9db77a9702 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -94,7 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
                  'cnxk_telemetry_sso.c',
 )
 
-cflags += no_wvla_cflag
 cflags += no_shadow_cflag
 
 if meson.is_cross_build()
-- 
2.51.0

Re: [PATCH v6 3/6] common/cnxk: re-enable vla warnings

[Nithin Dabilpuram]

Acked-by: Nithin Dabilpuram <ndabilpuram@marvell.com>

On Thu, Feb 5, 2026 at 11:28 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The code in common/cnxk no longer uses VLAs.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  drivers/common/cnxk/meson.build | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
> index 2b33022eb7..9db77a9702 100644
> --- a/drivers/common/cnxk/meson.build
> +++ b/drivers/common/cnxk/meson.build
> @@ -94,7 +94,6 @@ sources += files('cnxk_telemetry_bphy.c',
>                   'cnxk_telemetry_sso.c',
>  )
>
> -cflags += no_wvla_cflag
>  cflags += no_shadow_cflag
>
>  if meson.is_cross_build()
> --
> 2.51.0
>

[PATCH v6 4/6] common/cnxk: fix buffer overflow in SA setup

[Stephen Hemminger]

The nix_inl_reass_inb_sa_tbl_setup() function initializes inb_sa_sz
to 1 byte, then allocates a buffer of that size. However, the buffer
is subsequently passed to roc_ow_reass_inb_sa_init() which performs:

    memset(sa, 0, sizeof(struct roc_ow_ipsec_inb_sa));

This writes 808 bytes into a 1-byte allocation, causing heap corruption.

This bug was detected by GCC's -Wstringop-overflow warning when
building with LTO, which enables cross-compilation-unit inlining
and allows the compiler to track the allocation size through to
the memset call.

Fix by initializing inb_sa_sz to ROC_NIX_INL_OW_IPSEC_INB_SA_SZ,
which is the standard macro used elsewhere in this file for OW
(Sobek) inbound SA allocations.

Bugzilla ID: 1513
Fixes: fc9a711b5c8f ("common/cnxk: add NIX inline reassembly profile config")
Cc: rbhansali@marvell.com
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/common/cnxk/roc_nix_inl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_inl.c b/drivers/common/cnxk/roc_nix_inl.c
index f8be98efd5..1766f68c17 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -583,7 +583,7 @@ nix_inl_reass_inb_sa_tbl_setup(struct roc_nix *roc_nix)
 	uint64_t sa_idx_w, lenm1_max;
 	uint64_t res_addr_offset = 0;
 	uint64_t def_cptq = 0;
-	size_t inb_sa_sz = 1;
+	size_t inb_sa_sz = ROC_NIX_INL_OW_IPSEC_INB_SA_SZ;
 	uint8_t profile_id;
 	struct mbox *mbox;
 	void *sa;
-- 
2.51.0

Re: [PATCH v6 4/6] common/cnxk: fix buffer overflow in SA setup

[Nithin Dabilpuram]

Acked-by: Nithin Dabilpuram <ndabilpuram@marvell.com>

On Thu, Feb 5, 2026 at 11:34 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The nix_inl_reass_inb_sa_tbl_setup() function initializes inb_sa_sz
> to 1 byte, then allocates a buffer of that size. However, the buffer
> is subsequently passed to roc_ow_reass_inb_sa_init() which performs:
>
>     memset(sa, 0, sizeof(struct roc_ow_ipsec_inb_sa));
>
> This writes 808 bytes into a 1-byte allocation, causing heap corruption.
>
> This bug was detected by GCC's -Wstringop-overflow warning when
> building with LTO, which enables cross-compilation-unit inlining
> and allows the compiler to track the allocation size through to
> the memset call.
>
> Fix by initializing inb_sa_sz to ROC_NIX_INL_OW_IPSEC_INB_SA_SZ,
> which is the standard macro used elsewhere in this file for OW
> (Sobek) inbound SA allocations.
>
> Bugzilla ID: 1513
> Fixes: fc9a711b5c8f ("common/cnxk: add NIX inline reassembly profile config")
> Cc: rbhansali@marvell.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  drivers/common/cnxk/roc_nix_inl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/common/cnxk/roc_nix_inl.c b/drivers/common/cnxk/roc_nix_inl.c
> index f8be98efd5..1766f68c17 100644
> --- a/drivers/common/cnxk/roc_nix_inl.c
> +++ b/drivers/common/cnxk/roc_nix_inl.c
> @@ -583,7 +583,7 @@ nix_inl_reass_inb_sa_tbl_setup(struct roc_nix *roc_nix)
>         uint64_t sa_idx_w, lenm1_max;
>         uint64_t res_addr_offset = 0;
>         uint64_t def_cptq = 0;
> -       size_t inb_sa_sz = 1;
> +       size_t inb_sa_sz = ROC_NIX_INL_OW_IPSEC_INB_SA_SZ;
>         uint8_t profile_id;
>         struct mbox *mbox;
>         void *sa;
> --
> 2.51.0
>

[PATCH v6 5/6] ring: use inline instead of always inline in soring

[Stephen Hemminger]

With LTO enabled, always_inline forces GCC to inline the full
soring call chain, triggering a false -Wstringop-overflow
warning. GCC cannot prove the 128-bit element copy path is
unreachable when the ring uses 4-byte elements.

Use plain inline instead, giving the compiler discretion over
inlining. At -O2/-O3 these small hot functions are still
inlined by the compiler's own heuristics.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Tested-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/ring/soring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/ring/soring.c b/lib/ring/soring.c
index 797484d6bf..3b90521bdb 100644
--- a/lib/ring/soring.c
+++ b/lib/ring/soring.c
@@ -249,7 +249,7 @@ __rte_soring_stage_move_head(struct soring_stage_headtail *d,
 	return n;
 }
 
-static __rte_always_inline uint32_t
+static inline uint32_t
 soring_enqueue(struct rte_soring *r, const void *objs,
 	const void *meta, uint32_t n, enum rte_ring_queue_behavior behavior,
 	uint32_t *free_space)
@@ -278,7 +278,7 @@ soring_enqueue(struct rte_soring *r, const void *objs,
 	return n;
 }
 
-static __rte_always_inline uint32_t
+static inline uint32_t
 soring_dequeue(struct rte_soring *r, void *objs, void *meta,
 	uint32_t num, enum rte_ring_queue_behavior behavior,
 	uint32_t *available)
-- 
2.51.0

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

[Stephen Hemminger]

When LTO inlines mlx5dr_action_prepare_decap_l3_data() into
its callers, GCC sees the 64-byte stack buffer 'mh_data' but
cannot prove num_of_actions is bounded, producing a false
-Wstringop-overflow warning.

Add __rte_assume(num_of_actions <= DECAP_L3_NUM_ACTIONS_W_VLAN)
so GCC can verify the loop stays within buffer bounds.

Bugzilla ID: 1710
Fixes: f8c8a6d8440d ("net/mlx5/hws: add action object")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/net/mlx5/hws/mlx5dr_action.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c b/drivers/net/mlx5/hws/mlx5dr_action.c
index b35bf07c3c..afb638250d 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -3620,6 +3620,17 @@ mlx5dr_action_prepare_decap_l3_data(uint8_t *src, uint8_t *dst,
 	uint8_t *e_src;
 	int i;
 
+	/*
+	 * 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.
+	 */
+	__rte_assume(num_of_actions <= DECAP_L3_NUM_ACTIONS_W_VLAN);
+
 	/* 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

Re: [PATCH v6 6/6] net/mlx5: fix LTO stringop-overflow warning

[Dariusz Sosnowski]

On Thu, Feb 05, 2026 at 09:55:58AM -0800, Stephen Hemminger wrote:
> When LTO inlines mlx5dr_action_prepare_decap_l3_data() into
> its callers, GCC sees the 64-byte stack buffer 'mh_data' but
> cannot prove num_of_actions is bounded, producing a false
> -Wstringop-overflow warning.
> 
> Add __rte_assume(num_of_actions <= DECAP_L3_NUM_ACTIONS_W_VLAN)
> so GCC can verify the loop stays within buffer bounds.
> 
> Bugzilla ID: 1710
> Fixes: f8c8a6d8440d ("net/mlx5/hws: add action object")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

Re: [PATCH v6 0/6] Fix LTO compilation warnings

[David Marchand]

Hi Marvell guys,

On Thu, 5 Feb 2026 at 18:58, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> This series fixes compilation warnings and one buffer overflow bug
> exposed when building DPDK with Link Time Optimization (LTO) enabled.
>
> v6:
>   - net/mlx5: use __rte_assume() instead of runtime bounds check
>     per Dariusz Sosnowski's review, avoiding any overhead on the
>     flow creation fast path
>
> Stephen Hemminger (6):
>   common/cnxk: replace variable length state array
>   common/cnxk: replace variable length array
>   common/cnxk: re-enable vla warnings
>   common/cnxk: fix buffer overflow in SA setup
>   ring: use inline instead of always inline in soring
>   net/mlx5: fix LTO stringop-overflow warning
>
>  drivers/common/cnxk/meson.build      |  1 -
>  drivers/common/cnxk/roc_aes.c        |  3 ++-
>  drivers/common/cnxk/roc_nix_inl.c    |  2 +-
>  drivers/common/cnxk/roc_platform.c   |  4 ++--
>  drivers/net/mlx5/hws/mlx5dr_action.c | 11 +++++++++++
>  lib/ring/soring.c                    |  4 ++--
>  6 files changed, 18 insertions(+), 7 deletions(-)

Could you look at those common/cnxk patches please?


-- 
David Marchand

Re: [PATCH v6 0/6] Fix LTO compilation warnings

[David Marchand]

On Thu, 5 Feb 2026 at 18:58, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> This series fixes compilation warnings and one buffer overflow bug
> exposed when building DPDK with Link Time Optimization (LTO) enabled.
>
> v6:
>   - net/mlx5: use __rte_assume() instead of runtime bounds check
>     per Dariusz Sosnowski's review, avoiding any overhead on the
>     flow creation fast path
>
> Stephen Hemminger (6):
>   common/cnxk: replace variable length state array
>   common/cnxk: replace variable length array
>   common/cnxk: re-enable vla warnings
>   common/cnxk: fix buffer overflow in SA setup
>   ring: use inline instead of always inline in soring
>   net/mlx5: fix LTO stringop-overflow warning
>
>  drivers/common/cnxk/meson.build      |  1 -
>  drivers/common/cnxk/roc_aes.c        |  3 ++-
>  drivers/common/cnxk/roc_nix_inl.c    |  2 +-
>  drivers/common/cnxk/roc_platform.c   |  4 ++--
>  drivers/net/mlx5/hws/mlx5dr_action.c | 11 +++++++++++
>  lib/ring/soring.c                    |  4 ++--
>  6 files changed, 18 insertions(+), 7 deletions(-)

Series applied, thanks.


-- 
David Marchand