On Mon, 11 Aug 2025 16:37:14 -0700, Joe Damato wrote:

A couple pieces of feedback for you:

1. Since this is a fixes it needs a Fixes tag and a commit SHA that it is fixing.

Thank you very much for your feedback.I will add the Fixes tag as suggested.

2. cgx_get_cgxid is called in 3 places, so your patch would probably need to
  be expanded to fix all uses?

Thanks for the suggestion.
I can add a similar check in cgxlmac_to_pf() to check if cgx_id is
negative and return an error.

Overall though, did you somehow trigger this issue?

It seems like all cases where cgx_get_cgxid is used it would be extremely
difficult (maybe impossible?) for cgxd to be NULL and for it to return a
negative value.

I could not reproduce a scenario where cgx_get_cgxid returns a
negative value. However, this issue was reported by the Black Duck
Coverity scan.
The fix was made to cover all possible return paths.

Please advise if you think there’s a better way to address it.

Thanks,
Chandra Mohan Sundar


On Tue, Aug 12, 2025 at 5:07 AM Joe Damato [off-list ref] wrote:

On Sun, Aug 10, 2025 at 11:33:27PM +0530, Chandra Mohan Sundar wrote:

quoted

The cgx_get_cgxid function may return a negative value.
Using this value directly as an array index triggers Coverity warnings.

Validate the returned value and handle the case gracefully.

Signed-off-by: Chandra Mohan Sundar <redacted>
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
index 8375f18c8e07..b14de93a2481 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c

@@ -3005,6 +3005,8 @@ static int cgx_print_fwdata(struct seq_file *s, int lmac_id)
              return -EAGAIN;

      cgx_id = cgx_get_cgxid(cgxd);
+     if (cgx_id < 0)
+             return -EINVAL;

      if (rvu->hw->lmac_per_cgx == CGX_LMACS_USX)
              fwdata =  &rvu->fwdata->cgx_fw_data_usx[cgx_id][lmac_id];

A couple pieces of feedback for you:

1. Since this is a fixes it needs a Fixes tag and a commit SHA that it is fixing.
2. cgx_get_cgxid is called in 3 places, so your patch would probably need to
   be expanded to fix all uses?

Overall though, did you somehow trigger this issue?

It seems like all cases where cgx_get_cgxid is used it would be extremely
difficult (maybe impossible?) for cgxd to be NULL and for it to return a
negative value.