[PATCH net v2 0/2] bnge fixes

[PATCH net v2 0/2] bnge fixes

[Vikas Gupta]

Hi,

This series fixes RSS indirection table and context sizing for large RX
ring counts. Patch 1 caps the hardware RSS context count and RX rings
to the RSS table size, preventing out-of-bounds writes and an oversized
memset(). Patch 2 fixes the indirection table sizing so rings above
the table size still receive default RSS traffic.

Thanks,
Vikas

v1->v2:
  - Fix Sashiko (Nipa) review comments.

Dharmender Garg (2):
  bnge: cap RSS contexts and RX rings to the RSS table size
  bnge: fix RSS table sizing for large RX ring counts

 drivers/net/ethernet/broadcom/bnge/bnge_netdev.c | 10 +++++-----
 drivers/net/ethernet/broadcom/bnge/bnge_resc.c   |  6 ++++--
 drivers/net/ethernet/broadcom/bnge/bnge_resc.h   | 11 +++++++++++
 3 files changed, 20 insertions(+), 7 deletions(-)

-- 
2.52.0

[PATCH net v2 1/2] bnge: cap RSS contexts and RX rings to the RSS table size

[Vikas Gupta]

From: Dharmender Garg <dharmender.garg@broadcom.com>

The hardware supports at most BNGE_RSS_TABLE_MAX_TBL (8) RSS contexts.
They are stored in vnic->fw_rss_cos_lb_ctx[8] and back a 512-entry
(BNGE_MAX_RSS_TABLE_ENTRIES) indirection table and DMA buffer, so at most
512 RX rings can be served by RSS.

bnge_cal_nr_rss_ctxs() has no upper bound, so with more RX rings it
returns more than 8 contexts: bnge_setup_vnic() writes past
fw_rss_cos_lb_ctx[], bnge_set_dflt_rss_indir_tbl() and
bnge_fill_hw_rss_tbl() write past the indirection table and its DMA
buffer, and the pad computation in bnge_set_dflt_rss_indir_tbl()
underflows into a huge memset().

Cap the number of contexts at BNGE_RSS_TABLE_MAX_TBL and the number of RX
rings at BNGE_MAX_RSS_TABLE_ENTRIES, so the sizes derived from the ring
count always fit the arrays.

Fixes: 627c67f038d2 ("bng_en: Add resource management support")
Signed-off-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnge/bnge_resc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_resc.c b/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
index 4711dd4945ff..b540eed12fc6 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
@@ -182,8 +182,9 @@ int bnge_cal_nr_rss_ctxs(u16 rx_rings)
 	if (!rx_rings)
 		return 0;
 
-	return bnge_adjust_pow_two(rx_rings - 1,
-				   BNGE_RSS_TABLE_ENTRIES);
+	return min_t(int, bnge_adjust_pow_two(rx_rings - 1,
+					      BNGE_RSS_TABLE_ENTRIES),
+		     BNGE_RSS_TABLE_MAX_TBL);
 }
 
 static u16 bnge_rss_ctxs_in_use(struct bnge_dev *bd,
@@ -459,6 +460,7 @@ static void _bnge_get_max_rings(struct bnge_dev *bd, u16 *max_rx,
 	}
 
 	*max_rx = min_t(int, *max_rx, max_ring_grps);
+	*max_rx = min_t(int, *max_rx, BNGE_MAX_RSS_TABLE_ENTRIES);
 }
 
 static int bnge_get_max_rings(struct bnge_dev *bd, u16 *max_rx,
-- 
2.52.0

[PATCH net v2 2/2] bnge: fix RSS table sizing for large RX ring counts

[Vikas Gupta]

From: Dharmender Garg <dharmender.garg@broadcom.com>

bnge_adjust_pow_two() adds one block before rounding up to a power of
two only when the quotient is 0 or 1. A larger quotient that is
already a power of two is returned unchanged, so 129-192 RX rings
get a 128-entry RSS indirection table and 257-320 rings a 256-entry
one. The rings above the table size never receive default RSS traffic.
bnxt_calc_nr_ring_pages() always adds one, which is correct.

Make bnge_adjust_pow_two() always add one block before rounding up.
The same helper also sized the ring pages; to keep the ring size
calculation unchanged, move that to a separate bnge_calc_nr_ring_pages()
helper that retains the original rounding.

Fixes: 627c67f038d2 ("bng_en: Add resource management support")
Signed-off-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnge/bnge_netdev.c | 10 +++++-----
 drivers/net/ethernet/broadcom/bnge/bnge_resc.h   | 11 +++++++++++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
index a4288f0258f8..ecba8aff3052 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
@@ -3339,8 +3339,8 @@ void bnge_set_ring_params(struct bnge_dev *bd)
 		}
 		agg_ring_size = ring_size * agg_factor;
 
-		bn->rx_agg_nr_pages = bnge_adjust_pow_two(agg_ring_size,
-							  RX_DESC_CNT);
+		bn->rx_agg_nr_pages = bnge_calc_nr_ring_pages(agg_ring_size,
+							      RX_DESC_CNT);
 		if (bn->rx_agg_nr_pages > MAX_RX_AGG_PAGES) {
 			u32 tmp = agg_ring_size;
 
@@ -3363,11 +3363,11 @@ void bnge_set_ring_params(struct bnge_dev *bd)
 	bn->rx_buf_use_size = rx_size;
 	bn->rx_buf_size = rx_space;
 
-	bn->rx_nr_pages = bnge_adjust_pow_two(ring_size, RX_DESC_CNT);
+	bn->rx_nr_pages = bnge_calc_nr_ring_pages(ring_size, RX_DESC_CNT);
 	bn->rx_ring_mask = (bn->rx_nr_pages * RX_DESC_CNT) - 1;
 
 	ring_size = bn->tx_ring_size;
-	bn->tx_nr_pages = bnge_adjust_pow_two(ring_size, TX_DESC_CNT);
+	bn->tx_nr_pages = bnge_calc_nr_ring_pages(ring_size, TX_DESC_CNT);
 	bn->tx_ring_mask = (bn->tx_nr_pages * TX_DESC_CNT) - 1;
 
 	max_rx_cmpl = bn->rx_ring_size;
@@ -3377,7 +3377,7 @@ void bnge_set_ring_params(struct bnge_dev *bd)
 	ring_size = max_rx_cmpl * 2 + agg_ring_size + bn->tx_ring_size;
 	bn->cp_ring_size = ring_size;
 
-	bn->cp_nr_pages = bnge_adjust_pow_two(ring_size, CP_DESC_CNT);
+	bn->cp_nr_pages = bnge_calc_nr_ring_pages(ring_size, CP_DESC_CNT);
 	if (bn->cp_nr_pages > MAX_CP_PAGES) {
 		bn->cp_nr_pages = MAX_CP_PAGES;
 		bn->cp_ring_size = MAX_CP_PAGES * CP_DESC_CNT - 1;
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_resc.h b/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
index b62a634669f6..58462524939f 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
@@ -81,6 +81,17 @@ bnge_adjust_pow_two(u32 total_ent, u16 ent_per_blk)
 {
 	u32 blks = total_ent / ent_per_blk;
 
+	if (!blks)
+		return 1;
+
+	return roundup_pow_of_two(blks + 1);
+}
+
+static inline u32
+bnge_calc_nr_ring_pages(u32 total_ent, u16 ent_per_blk)
+{
+	u32 blks = total_ent / ent_per_blk;
+
 	if (blks == 0 || blks == 1)
 		return ++blks;
 
-- 
2.52.0

Re: [PATCH net v2 0/2] bnge fixes

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v2 0/2] bnge fixes

[Vikas Gupta]

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

Hi,
  We found these issues during the Sashiko code review.
  The fixes were tested on the Thor Ultra platform.

Thanks,
Vikas

On Thu, Oct 15, 2026 at 5:55 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5465 bytes --]

Re: [PATCH net v2 2/2] bnge: fix RSS table sizing for large RX ring counts

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] This patch adds a new helper, bnge_calc_nr_ring_pages()
  (drivers/net/ethernet/broadcom/bnge/bnge_resc.h:90-102), that keeps…

--

bnge: fix RSS table sizing for large RX ring counts

This commit changes bnge_adjust_pow_two() so it always adds one block
before rounding up to a power of two. With that change the RSS indirection
table covers every RX ring. Ring page sizing moves to a new
bnge_calc_nr_ring_pages() helper, which keeps the original rounding.

> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_resc.h b/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
> index b62a634669f62..58462524939fe 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_resc.h
> @@ -81,6 +81,17 @@ bnge_adjust_pow_two(u32 total_ent, u16 ent_per_blk)
>  {
>  	u32 blks = total_ent / ent_per_blk;
>  
> +	if (!blks)
> +		return 1;
> +
> +	return roundup_pow_of_two(blks + 1);
> +}
> +
> +static inline u32
> +bnge_calc_nr_ring_pages(u32 total_ent, u16 ent_per_blk)
> +{
> +	u32 blks = total_ent / ent_per_blk;
> +
>  	if (blks == 0 || blks == 1)
>  		return ++blks;
>  

[Severity: Medium]
Can this new helper size a ring smaller than total_ent?

The rest of bnge_calc_nr_ring_pages() is:

	if (!is_power_of_2(blks))
		blks = roundup_pow_of_two(blks);

	return blks;

If the floored quotient is already a power of two of 2 or more, blks is
returned unchanged and the partial last page is lost. The ring then has
blks * ent_per_blk slots, which is never more than total_ent.

The commit message says "bnxt_calc_nr_ring_pages() always adds one, which
is correct". This helper has the same name but keeps the rounding that the
message calls wrong.

In bnge_set_ring_params(), the completion ring budget includes
max_tpa_v2. bnge_hwrm_vnic_qcaps() takes that value from the firmware's
max_aggs_supported without any cap:

	max_rx_cmpl = bn->rx_ring_size;

	if (bn->priv_flags & BNGE_NET_EN_TPA)
		max_rx_cmpl += bd->max_tpa_v2;
	ring_size = max_rx_cmpl * 2 + agg_ring_size + bn->tx_ring_size;
	bn->cp_ring_size = ring_size;

	bn->cp_nr_pages = bnge_calc_nr_ring_pages(ring_size, CP_DESC_CNT);
	...
	bn->cp_bit = bn->cp_nr_pages * CP_DESC_CNT;
	bn->cp_ring_mask = bn->cp_bit - 1;

hwrm_ring_alloc_send_msg() then sets the CMPL and NQ ring lengths from
that mask:

	req->length = cpu_to_le32(bn->cp_ring_mask + 1);

Take 4K pages, rx/tx ring size 511, agg_factor 4 (TPA is on by default)
and CP_DESC_CNT 256. Then ring_size is 3577 + 2 * max_tpa_v2.

Any max_tpa_v2 from 260 to 387 gives a ring_size of 4097 to 4351. That
means blks = 16 and a 4096-entry completion ring, while bn->cp_ring_size
keeps the larger budget. The MAX_CP_PAGES clamp cannot catch this,
because the page count has already been rounded down.

With 64K pages (agg_factor 2, CP_DESC_CNT 4096), any max_tpa_v2 from 2819
to 4866 gives blks = 2. That is 8192 slots for up to 12287 budgeted
completions.

Could the completion ring overflow if the driver reaches that worst case?
I could not confirm whether shipping firmware reports max_aggs_supported
in those ranges.

The RX, RX agg and TX ring sizing use the same helper. They are only safe
today because the ring sizes are fixed at 511 and bnge has no
set_ringparam. A tx_ring_size between 512 and 767 would give
tx_ring_mask = 511, and bnge_tx_avail() would then report more free space
than the ring has.

The helper also breaks the rule encoded in BNGE_MAX_RX_DESC_CNT and
BNGE_MAX_TX_DESC_CNT, which keep the ring size below pages * DESC_CNT.

Should ring pages use the always-add-one rounding as well, the way
bnxt_calc_nr_ring_pages() does? If dropping the remainder is safe, could a
comment or the commit message explain why?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261015121847.1933308-1-vikas.gupta%40broadcom.com