From: Jakub Kicinski <kuba@kernel.org>
To: subratp@marvell.com
Cc: Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, edumazet@google.com, davem@davemloft.net,
andrew+netdev@lunn.ch, sbhatta@marvell.com, rkannoth@marvell.com,
gakula@marvell.com, sgoutham@marvell.com
Subject: Re: [PATCH net v6 1/2] octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled
Date: Wed, 16 Sep 2026 19:03:40 -0700 [thread overview]
Message-ID: <20260917020340.2544315-1-kuba@kernel.org> (raw)
In-Reply-To: <20260910062657.3712256-2-subratp@marvell.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.
---
octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled
This consolidates the per-file CONFIG_DCB ifdef blocks that pick the BPID
index for CQ and aura contexts into a new otx2_get_bpid_idx() helper in
otx2_common.h, and drops the equivalent cn20k_aura_bpid_idx().
> Previously, BPID assignment under CONFIG_DCB assumed
> `queue_to_pfc_map` was always initialized. For SDP VFs this leads to
> invalid memory access as it was not initialized.
>
> This patch adds a NULL check for `queue_to_pfc_map` before
> dereferencing it. Also, simplifies the logic by always assigning a
> default BPID first, then conditionally overriding it if CONFIG_DCB is
> enabled and the map exists.
[Severity: High]
Does the patch match this description? I do not see a NULL check for
queue_to_pfc_map anywhere in the diff, and no place where a default BPID is
assigned first and then conditionally overridden. The new helper appears to
dereference the map unconditionally when CONFIG_DCB=y, which looks
byte-for-byte equivalent to the ifdef blocks it replaces.
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> index eecee612b7b2c..2a63d22cbd8d0 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> @@ -1029,6 +1029,14 @@ static inline int otx2_tc_flower_rule_cnt(struct otx2_nic *pfvf)
> return pfvf->flow_cfg->nr_flows;
> }
>
> +static inline u8 otx2_get_bpid_idx(struct otx2_nic *pfvf, int qidx)
> +{
> +#ifdef CONFIG_DCB
> + return pfvf->queue_to_pfc_map[qidx];
> +#endif
> + return 0;
> +}
> +
[Severity: High]
With CONFIG_DCB=y, isn't the trailing return 0 dead code here, leaving
pfvf->queue_to_pfc_map[qidx] as an unguarded dereference?
queue_to_pfc_map is allocated only in otx2_dcbnl_set_ops():
drivers/net/ethernet/marvell/octeontx2/nic/otx2_dcbnl.c:otx2_dcbnl_set_ops() {
pfvf->queue_to_pfc_map = devm_kzalloc(pfvf->dev, pfvf->hw.rx_queues,
GFP_KERNEL);
}
and since the Fixes: commit, otx2vf_probe() skips that call for SDP and LBK
VFs:
drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c:otx2vf_probe() {
#ifdef CONFIG_DCB
/* Priority flow control is not supported for LBK and SDP vf(s) */
if (!(is_otx2_lbkvf(vf->pdev) || is_otx2_sdp_rep(vf->pdev))) {
err = otx2_dcbnl_set_ops(netdev);
#endif
}
so for an SDP VF the pointer stays NULL for the lifetime of the device.
Would something like this be what was intended?
static inline u8 otx2_get_bpid_idx(struct otx2_nic *pfvf, int qidx)
{
#ifdef CONFIG_DCB
if (pfvf->queue_to_pfc_map)
return pfvf->queue_to_pfc_map[qidx];
#endif
return 0;
}
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index 175992188c18a..0f3f405d9f1b7 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
[ ... ]
> @@ -1132,11 +1133,8 @@ int otx2_cq_init(struct otx2_nic *pfvf, u16 qidx)
> if (!is_otx2_lbkvf(pfvf->pdev)) {
> /* Enable receive CQ backpressure */
> aq->cq.bp_ena = 1;
> -#ifdef CONFIG_DCB
> - aq->cq.bpid = pfvf->bpid[pfvf->queue_to_pfc_map[qidx]];
> -#else
> - aq->cq.bpid = pfvf->bpid[0];
> -#endif
> + bpid_idx = otx2_get_bpid_idx(pfvf, qidx);
> + aq->cq.bpid = pfvf->bpid[bpid_idx];
[Severity: High]
Does this call site still oops on an SDP VF with CONFIG_DCB=y? The only
guard here is !is_otx2_lbkvf(), which matches PCI_DEVID_OCTEONTX2_RVU_AFVF
and PCI_DEVID_RVU_REP but not PCI_DEVID_OCTEONTX2_SDP_REP:
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h {
static inline bool is_otx2_lbkvf(struct pci_dev *pdev)
{
return (pdev->device == PCI_DEVID_OCTEONTX2_RVU_AFVF) ||
(pdev->device == PCI_DEVID_RVU_REP);
}
}
so interface bring up on an SDP VF reaches otx2_get_bpid_idx() with a NULL
map:
ndo_open -> otx2_init_hw_resources() -> otx2_cq_init() ->
otx2_get_bpid_idx()
The same holds for the other two converted sites, which carry identical
guards:
otx2_init_hw_resources() -> otx2_rq_aura_pool_init() ->
otx2_aura_aq_init() -> otx2_get_bpid_idx()
and cn20k_aura_aq_init() -> otx2_get_bpid_idx(), where the removed
cn20k_aura_bpid_idx() had the same shape.
Given the Fixes: tag will pull this into stable, could the helper be
respun with the guard the changelog describes, so that SDP VFs fall back to
pfvf->bpid[0]?
[ ... ]
--
pw-bot: cr
next prev parent reply other threads:[~2026-09-17 2:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 6:26 [PATCH net v6 0/2] octeontx2: Misc fixes for RVU drivers Subrat Pandey
2026-09-10 6:26 ` [PATCH net v6 1/2] octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled Subrat Pandey
2026-09-17 2:03 ` Jakub Kicinski [this message]
2026-09-10 6:26 ` [PATCH net v6 2/2] octeontx2-af: mcs: Fix SC resource cleanup loop Subrat Pandey
2026-09-17 2:03 ` Jakub Kicinski
2026-09-17 2:03 ` [PATCH net v6 0/2] octeontx2: Misc fixes for RVU drivers Jakub Kicinski
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=20260917020340.2544315-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rkannoth@marvell.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
--cc=subratp@marvell.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
all inboxes | Powered by JetHome®