Re: [PATCH v12 net-next] octeontx2-pf: add mqprio bandwidth offload for NIX TX schedulers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Divide-by-zero in SMQ lookup during MQPRIO rollback
--

commit ba1788f860ad0c3ea2631aca0bfc1b979830add7
Author: Ratheesh Kannoth <rkannoth@marvell.com>
Subject: octeontx2-pf: add mqprio bandwidth offload for NIX TX schedulers

This commit adds TC_SETUP_QDISC_MQPRIO offload for channel-mode mqprio using
the NIX TX scheduler mailbox. It programs per-queue MDQ shapers and handles
mqprio setup, replacement, and teardown by restarting the netdev and
caching active rates.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
[ ... ]
> +static int otx2_mqprio_restore_old(struct otx2_nic *pfvf)
> +{
[ ... ]
> +	if (otx2_mqprio_mdq_allocated(pfvf)) {
> +		err = otx2_nix_tm_clear_queue_shaper(pfvf);
> +		if (err)
> +			return err;
> +	}
> +
> +	/* otx2_mqprio_restart_netdev() clears rate_limit when ndo_open() fails. */
> +	pfvf->mqprio.rate_limit = true;
> +
> +	err = otx2_mqprio_up(pfvf);

[Severity: High]
Can this lead to a divide-by-zero if ndo_open() fails during the replacement?

In otx2_setup_tc_mqprio(), if otx2_mqprio_restart_netdev() fails (e.g., due
to an allocation failure), the interface is left stopped and the TX schedulers
are freed, setting pfvf->hw.txschq_cnt[NIX_TXSCH_LVL_SMQ] to 0.

The error path then calls this function, otx2_mqprio_restore_old(), which
unconditionally sets rate_limit to true and calls otx2_mqprio_up() to restore
the shapers.

otx2_mqprio_up() calls otx2_nix_tm_set_queue_shaper(), which eventually
invokes otx2_get_smq_idx():

otx2_common.h:otx2_get_smq_idx() {
    ...
    idx = qidx % pfvf->hw.txschq_cnt[NIX_TXSCH_LVL_SMQ];
    smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][idx];
    ...
}

Since txschq_cnt is 0, won't this cause a divide-by-zero panic, or silently
evaluate to an out-of-bounds index on architectures that do not trap on
integer division, leading to malformed configuration commands being sent
to the hardware?

> +	if (err)
> +		return err;
> +
> +	otx2_mqprio_snap_free(pfvf, &pfvf->cur_mq_snap);
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903023324.3078284-1-rkannoth@marvell.com?part=1