[PATCH] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[PATCH] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[Gagandeep Singh]

From: David Marchand <david.marchand@redhat.com>

The conversion loop is bounded only by num, which is not checked
unless RTE_LIBRTE_DPAA_HWDEBUG is set. GCC on ppc64le and riscv
therefore warns that bm_bufs[0] may be read uninitialized when
copying the first entry into the RCR.

Convert entry 0 unconditionally, as bman_release() does.

Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
Cc: jun.yang@nxp.com

Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 drivers/bus/dpaa/base/qbman/bman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 2b081cb78a..76e612662f 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -279,7 +279,8 @@ bman_release_fast(struct bman_pool *pool, const uint64_t *bufs,
 	if (unlikely(!r))
 		return -EBUSY;
 
-	for (i = 0; i < num; i++)
+	bm_buffer_set64_to_be(&bm_bufs[0], bufs[0]);
+	for (i = 1; i < num; i++)
 		bm_buffer_set64_to_be(&bm_bufs[i], bufs[i]);
 
 	/* bufs[0] overlaps the verb, which bm_rcr_pvb_commit() writes last
-- 
2.25.1

[PATCH v2 0/1] DPAA compilation fix ppc64le and riscv

[Gagandeep Singh]

V2-changes:
- updated the Author name.

Stephen Hemminger (1):
  bus/dpaa: fix maybe-uninitialized in bman_release_fast

 drivers/bus/dpaa/base/qbman/bman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH v2 1/1] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[Gagandeep Singh]

From: Stephen Hemminger <stephen@networkplumber.org>

The conversion loop is bounded only by num, which is not checked
unless RTE_LIBRTE_DPAA_HWDEBUG is set. GCC on ppc64le and riscv
therefore warns that bm_bufs[0] may be read uninitialized when
copying the first entry into the RCR.

Convert entry 0 unconditionally, as bman_release() does.

Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
Cc: jun.yang@nxp.com

Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/bus/dpaa/base/qbman/bman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 2b081cb78a..76e612662f 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -279,7 +279,8 @@ bman_release_fast(struct bman_pool *pool, const uint64_t *bufs,
 	if (unlikely(!r))
 		return -EBUSY;
 
-	for (i = 0; i < num; i++)
+	bm_buffer_set64_to_be(&bm_bufs[0], bufs[0]);
+	for (i = 1; i < num; i++)
 		bm_buffer_set64_to_be(&bm_bufs[i], bufs[i]);
 
 	/* bufs[0] overlaps the verb, which bm_rcr_pvb_commit() writes last
-- 
2.25.1

Re: [PATCH v2 1/1] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[David Marchand]

On Tue, 27 Oct 2026 at 07:31, Gagandeep Singh <g.singh@nxp.com> wrote:
>
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> The conversion loop is bounded only by num, which is not checked
> unless RTE_LIBRTE_DPAA_HWDEBUG is set. GCC on ppc64le and riscv
> therefore warns that bm_bufs[0] may be read uninitialized when
> copying the first entry into the RCR.
>
> Convert entry 0 unconditionally, as bman_release() does.

bman_release() looks wrong if called with num == 0 without debug flag.
This should be fixed (probably better in a followup patch as it does
not directly relate to the Fixes: tag).
It seems a simple fix is to not assign i variable in the first place
and remove the check on i before the for loop. Just rely on the for
loop check condition.


> Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
> Cc: jun.yang@nxp.com
>
> Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

This current fix lgtm though we don't have CI that ran on it because
CI tested it against main.

It should go through next-net where it can be squashed in the original commit.


-- 
David Marchand

[PATCH v3 0/2] DPAA compilation fix ppc64le and riscv

[Gagandeep Singh]

V3-changes:
- fixed num usage in bman_release()

V2-changes:
- updated the Author name.

Gagandeep Singh (1):
  bus/dpaa: fix unneeded conditional in bman_release

Stephen Hemminger (1):
  bus/dpaa: fix maybe-uninitialized in bman_release_fast

 drivers/bus/dpaa/base/qbman/bman.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.25.1

[PATCH v3 1/2] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[Gagandeep Singh]

From: Stephen Hemminger <stephen@networkplumber.org>

The conversion loop is bounded only by num, which is not checked
unless RTE_LIBRTE_DPAA_HWDEBUG is set. GCC on ppc64le and riscv
therefore warns that bm_bufs[0] may be read uninitialized when
copying the first entry into the RCR.

Convert entry 0 unconditionally, as bman_release() does.

Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
Cc: jun.yang@nxp.com

Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/bus/dpaa/base/qbman/bman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 2b081cb78a..76e612662f 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -279,7 +279,8 @@ bman_release_fast(struct bman_pool *pool, const uint64_t *bufs,
 	if (unlikely(!r))
 		return -EBUSY;
 
-	for (i = 0; i < num; i++)
+	bm_buffer_set64_to_be(&bm_bufs[0], bufs[0]);
+	for (i = 1; i < num; i++)
 		bm_buffer_set64_to_be(&bm_bufs[i], bufs[i]);
 
 	/* bufs[0] overlaps the verb, which bm_rcr_pvb_commit() writes last
-- 
2.25.1

[PATCH v3 2/2] bus/dpaa: fix unneeded conditional in bman_release

[Gagandeep Singh]

bman_release() computed i = num - 1 before the num == 0 bounds check,
which only exists under RTE_LIBRTE_DPAA_HWDEBUG. With that debug flag
disabled and num == 0, i wraps to UINT32_MAX, and the subsequent
'if (i)' guard is then always taken regardless of num, relying on the
for loop's own bound to do nothing. The indirection added no value and
obscured the num == 0 handling.

Drop the i = num - 1 initializer and the if (i) wrapper, relying
solely on the for (i = 1; i < num; i++) loop condition, matching the
simpler pattern already used in bman_release_fast().

Fixes: f38f61e982f8 ("bus/dpaa: add BMAN hardware interfaces")

Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
---
 drivers/bus/dpaa/base/qbman/bman.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 76e612662f..31114b2d57 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -304,7 +304,7 @@ int bman_release(struct bman_pool *pool, const struct bm_buffer *bufs, u8 num,
 {
 	struct bman_portal *p;
 	struct bm_rcr_entry *r;
-	u32 i = num - 1;
+	u32 i;
 	u8 avail;
 
 #ifdef RTE_LIBRTE_DPAA_HWDEBUG
@@ -329,11 +329,9 @@ int bman_release(struct bman_pool *pool, const struct bm_buffer *bufs, u8 num,
 	r->bufs[0].opaque =
 		cpu_to_be64(((u64)pool->params.bpid << 48) |
 			    (bufs[0].opaque & MAX_U48));
-	if (i) {
-		for (i = 1; i < num; i++)
-			r->bufs[i].opaque =
-				cpu_to_be64(bufs[i].opaque & MAX_U48);
-	}
+	for (i = 1; i < num; i++)
+		r->bufs[i].opaque =
+			cpu_to_be64(bufs[i].opaque & MAX_U48);
 
 	bm_rcr_pvb_commit(&p->p, BM_RCR_VERB_CMD_BPID_SINGLE |
 			  (num & BM_RCR_VERB_BUFCOUNT_MASK));
-- 
2.25.1

Re: [PATCH v2 1/1] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[Stephen Hemminger]

On Tue, 27 Oct 2026 08:48:53 +0100
David Marchand <david.marchand@redhat.com> wrote:

> > Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
> > Cc: jun.yang@nxp.com
> >
> > Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>  
> 
> This current fix lgtm though we don't have CI that ran on it because
> CI tested it against main.
> 
> It should go through next-net where it can be squashed in the original commit.


Applied and squashed, will push update today after backlog is cleared

[PATCH v2 1/1] bus/dpaa: fix maybe-uninitialized in bman_release_fast

[Gagandeep Singh]

From: Stephen Hemminger <stephen@networkplumber.org>

The conversion loop is bounded only by num, which is not checked
unless RTE_LIBRTE_DPAA_HWDEBUG is set. GCC on ppc64le and riscv
therefore warns that bm_bufs[0] may be read uninitialized when
copying the first entry into the RCR.

Convert entry 0 unconditionally, as bman_release() does.

Fixes: e55e2e2d0c66 ("bus/dpaa: optimize DPAA multi-entry buffer pool operations")
Cc: jun.yang@nxp.com

Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/bus/dpaa/base/qbman/bman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 2b081cb78a..76e612662f 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -279,7 +279,8 @@ bman_release_fast(struct bman_pool *pool, const uint64_t *bufs,
 	if (unlikely(!r))
 		return -EBUSY;
 
-	for (i = 0; i < num; i++)
+	bm_buffer_set64_to_be(&bm_bufs[0], bufs[0]);
+	for (i = 1; i < num; i++)
 		bm_buffer_set64_to_be(&bm_bufs[i], bufs[i]);
 
 	/* bufs[0] overlaps the verb, which bm_rcr_pvb_commit() writes last
-- 
2.25.1