From: Jakub Kicinski <kuba@kernel.org>
To: bhargava.marreddy@broadcom.com
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, vikas.gupta@broadcom.com,
vsrama-krishna.nemani@broadcom.com, pabeni@redhat.com,
rajashekar.hudumula@broadcom.com, rahul-rg.gupta@broadcom.com,
davem@davemloft.net, edumazet@google.com,
pavan.chebbi@broadcom.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, horms@kernel.org,
ajit.khaparde@broadcom.com, michael.chan@broadcom.com
Subject: Re: [v5,net-next,8/8] bng_en: Add support for TPA events
Date: Mon, 19 Jan 2026 11:45:53 -0800 [thread overview]
Message-ID: <20260119194553.1264793-1-kuba@kernel.org> (raw)
In-Reply-To: <20260116193732.157898-9-bhargava.marreddy@broadcom.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
bng_en: Add support for TPA events
This patch enables TPA (Transparent Packet Aggregation) functionality
in the VNIC and adds functions to handle TPA events for LRO/GRO
processing.
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h
[ ... ]
> @@ -159,10 +159,9 @@ enum {
> #define MAX_TPA_MASK (MAX_TPA - 1)
> #define MAX_TPA_SEGS 0x3f
>
> -#define BNGE_AGG_IDX_BMAP_SIZE (MAX_TPA / BITS_PER_LONG)
> struct bnge_tpa_idx_map {
> u16 agg_id_tbl[1024];
> - unsigned long agg_idx_bmap[BNGE_AGG_IDX_BMAP_SIZE];
> + DECLARE_BITMAP(agg_idx_bmap, MAX_TPA);
> };
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_txrx.c b/drivers/net/ethernet/broadcom/bnge/bnge_txrx.c
[ ... ]
> +static u16 bnge_tpa_alloc_agg_idx(struct bnge_rx_ring_info *rxr, u16 agg_id)
> +{
> + struct bnge_tpa_idx_map *map = rxr->rx_tpa_idx_map;
> + u16 idx = agg_id & MAX_TPA_MASK;
> +
> + if (test_bit(idx, map->agg_idx_bmap)) {
> + idx = find_first_zero_bit(map->agg_idx_bmap, MAX_TPA);
> + if (idx >= MAX_TPA)
> + return INVALID_HW_RING_ID;
> + }
> + __set_bit(idx, map->agg_idx_bmap);
> + map->agg_id_tbl[agg_id] = idx;
^^^^^^
The agg_id_tbl array is 1024 elements, but agg_id comes from hardware via
TPA_START_AGG_ID() which uses mask RX_TPA_START_CMP_AGG_ID_P5 (0xffff << 16),
allowing values up to 65535. Can this write out of bounds when
agg_id >= 1024?
For reference, the bnxt driver uses a different mask (0x0fff << 16),
limiting agg_id to 0-4095.
> + return idx;
> +}
[ ... ]
> +static u16 bnge_lookup_agg_idx(struct bnge_rx_ring_info *rxr, u16 agg_id)
> +{
> + struct bnge_tpa_idx_map *map = rxr->rx_tpa_idx_map;
> +
> + return map->agg_id_tbl[agg_id];
^^^^^^
Same concern here - the array lookup has no bounds check on agg_id.
> +}
[ ... ]
> +static void bnge_tpa_start(struct bnge_net *bn, struct bnge_rx_ring_info *rxr,
> + u8 cmp_type, struct rx_tpa_start_cmp *tpa_start,
> + struct rx_tpa_start_cmp_ext *tpa_start1)
> +{
> + struct bnge_sw_rx_bd *cons_rx_buf, *prod_rx_buf;
> + struct bnge_tpa_info *tpa_info;
> + u16 cons, prod, agg_id;
> + struct rx_bd *prod_bd;
> + dma_addr_t mapping;
> +
> + agg_id = TPA_START_AGG_ID(tpa_start);
> + agg_id = bnge_tpa_alloc_agg_idx(rxr, agg_id);
> + if (unlikely(agg_id == INVALID_HW_RING_ID)) {
> + netdev_warn(bn->netdev, "Unable to allocate agg ID for ring %d, agg 0x%x\n",
> + rxr->bnapi->index, TPA_START_AGG_ID(tpa_start));
> + bnge_sched_reset_rxr(bn, rxr);
> + return;
> + }
> + cons = tpa_start->rx_tpa_start_cmp_opaque;
> + prod = rxr->rx_prod;
> + cons_rx_buf = &rxr->rx_buf_ring[cons];
> + prod_rx_buf = &rxr->rx_buf_ring[RING_RX(bn, prod)];
> + tpa_info = &rxr->rx_tpa[agg_id];
> +
> + if (unlikely(cons != rxr->rx_next_cons ||
> + TPA_START_ERROR(tpa_start))) {
> + netdev_warn(bn->netdev, "TPA cons %x, expected cons %x, error code %x\n",
> + cons, rxr->rx_next_cons,
> + TPA_START_ERROR_CODE(tpa_start1));
> + bnge_sched_reset_rxr(bn, rxr);
> + return;
^^^^^^
When this error path is taken, bnge_tpa_alloc_agg_idx() has already set
a bit in map->agg_idx_bmap but there is no corresponding call to
bnge_free_agg_idx(). Will this leak the TPA index, eventually
exhausting the available indices and causing subsequent TPA_START
events to fail?
> + }
[ ... ]
> +static void bnge_tpa_agg(struct bnge_net *bn, struct bnge_rx_ring_info *rxr,
> + struct rx_agg_cmp *rx_agg)
> +{
> + u16 agg_id = TPA_AGG_AGG_ID(rx_agg);
> + struct bnge_tpa_info *tpa_info;
> +
> + agg_id = bnge_lookup_agg_idx(rxr, agg_id);
> + tpa_info = &rxr->rx_tpa[agg_id];
If bnge_lookup_agg_idx() returns a garbage value due to out-of-bounds
read, does this risk accessing invalid memory here as well?
> +
> + tpa_info->agg_arr[tpa_info->agg_count++] = *rx_agg;
> +}
next prev parent reply other threads:[~2026-01-19 19:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 19:37 [v5, net-next 0/8] bng_en: enhancements for RX and TX datapath Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 1/8] bng_en: Extend bnge_set_ring_params() for rx-copybreak Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 2/8] bng_en: Add RX support Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 3/8] bng_en: Handle an HWRM completion request Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 4/8] bng_en: Add TX support Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 5/8] bng_en: Add ndo_features_check support Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 6/8] bng_en: Add support to handle AGG events Bhargava Marreddy
2026-01-19 19:45 ` [v5,net-next,6/8] " Jakub Kicinski
2026-01-23 17:42 ` Bhargava Chenna Marreddy
2026-01-16 19:37 ` [v5, net-next 7/8] bng_en: Add TPA related functions Bhargava Marreddy
2026-01-16 19:37 ` [v5, net-next 8/8] bng_en: Add support for TPA events Bhargava Marreddy
2026-01-19 19:45 ` Jakub Kicinski [this message]
2026-01-23 18:06 ` [v5,net-next,8/8] " Bhargava Chenna Marreddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260119194553.1264793-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew+netdev@lunn.ch \
--cc=bhargava.marreddy@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=rahul-rg.gupta@broadcom.com \
--cc=rajashekar.hudumula@broadcom.com \
--cc=vikas.gupta@broadcom.com \
--cc=vsrama-krishna.nemani@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox