Re: [PATCH iwl-next v4 06/15] ice: bump to 256qs for VF

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ice: u8 truncation of 256 VF queues in ice_aq_cfg_lan_txq()
--

commit 371721d1a3832397e9b3c3a095be6c11dcfbdd2d
Author: Przemek Kitszel <przemyslaw.kitszel@intel.com>

ice: bump to 256qs for VF

This commit adjusts bitmaps, arrays, and struct ice_vf::num_req_qs in ice
to accept up to 256 VF queues while keeping the 16-queue limit for legacy
virtchnl opcodes. It also raises the default VF queue count limit and the
VIRTCHNL_OP_REQUEST_QUEUES limit to 256, switching struct ice_lag
allocations to kvzalloc().

[ ... ]

> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> index 4959ecee0c21c..a9e95c85bc989 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> @@ -21,6 +21,7 @@
>  /* VF resource constraints */
>  /* for "old" virtchnl opcodes that accept up to 16 queues */
>  #define ICE_MAX_QS_PER_VF_VCV1	16
> +#define ICE_MAX_QS_PER_VF	256

[Severity: High]
When a VF is allocated 256 queues via ice_set_per_vf_res() or
ice_vc_request_qs_msg(), ice_vsi_cfg_tc_lan() -> ice_cfg_vsi_lan() ->
ice_sched_cfg_vsi() -> ice_alloc_lan_q_ctx() sets
ctx->num_lan_q_entries[0] to 256.

During SR-IOV Active-Backup LAG operations in
drivers/net/ethernet/intel/ice/ice_lag.c, ice_lag_reclaim_vf_tc() and
ice_lag_move_vf_nodes_tc_sync() pass numq = ctx->num_lan_q_entries[tc]
(which is 256 whenever the VF is allocated 256 queues and has at least one
valid queue) to ice_aq_cfg_lan_txq(), and ice_lag_move_vf_node_tc() passes
valq (256 when all 256 VF queues are configured) to ice_aq_cfg_lan_txq():

drivers/net/ethernet/intel/ice/ice_lag.c:ice_lag_reclaim_vf_tc() {
	...
	valq = ice_lag_qbuf_recfg(hw, qbuf, vsi_num, numq, tc);
	if (!valq) {
		dev_dbg(dev, "No valid queues found for LAG reclaim\n");
		goto reclaim_none;
	}

	if (ice_aq_cfg_lan_txq(hw, qbuf, qbuf_size, numq,
			       src_hw->port_info->lport, hw->port_info->lport,
			       ICE_AQC_Q_CFG_TC_CHNG, NULL)) {
	...
}

However, in drivers/net/ethernet/intel/ice/ice_adminq_cmd.h, the AdminQ
0x0C32 command descriptor struct ice_aqc_cfg_txqs defines num_qs as u8, and
ice_aq_cfg_lan_txq() assigns the u16 num_qs parameter directly to it:

drivers/net/ethernet/intel/ice/ice_common.c:ice_aq_cfg_lan_txq() {
	...
	cmd->cmd_type = mode;
	cmd->num_qs = num_qs;
	...
}

Doesn't this truncate num_qs from 256 to 0 in cmd->num_qs, causing firmware
queue reconfiguration to fail or misconfigure queues during LAG failover,
reclaim, or reset rebuild?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103141646.303620-1-przemyslaw.kitszel@intel.com?part=6