Re: [PATCH rdma-next 20/23] RDMA/mlx5: Clamp log_max_* shifts in QP and WQ limit checks

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message says each limit is computed from "an 8-bit
  log_max_* FW capability".

--

RDMA/mlx5: Clamp log_max_* shifts in QP and WQ limit checks

This commit replaces several open-coded 1 << MLX5_CAP_GEN(...) limit
calculations in drivers/infiniband/hw/mlx5/qp.c with
MLX5_CAP_GEN_LOGSZ_U32(). This avoids an undefined shift when a NIC
reports a log_max_* capability of 31 or more. The affected checks are in
set_rq_size(), calc_sq_size(), set_user_buf_size(), create_dci(),
create_user_qp(), validate_rd_atomic() and set_user_rq_size().

> Several QP and WQ size checks in qp.c compute their limit as
> 1 << cap, where cap is an 8-bit log_max_* FW capability. An untrusted
> NIC can report 31 or more, which makes the shift undefined.

[Severity: Low]
This isn't a bug, but is "an 8-bit log_max_* FW capability" accurate for
all the caps this patch touches?

In struct mlx5_ifc_cmd_hca_cap_bits in include/linux/mlx5/mlx5_ifc.h,
only log_max_qp_sz is 8 bits wide:

	u8         log_max_qp_sz[0x8];

The rd_atomic caps used by validate_rd_atomic() are 6 bits wide:

	u8         log_max_ra_req_dc[0x6];
	u8         log_max_ra_res_dc[0x6];
	u8         log_max_ra_req_qp[0x6];
	u8         log_max_ra_res_qp[0x6];

The cap used by set_user_rq_size() is 5 bits wide, so its maximum value
is exactly 31:

	u8         log_max_wq_sz[0x5];

The main point still holds, since every one of these fields can reach 31
and the shift can be undefined.

Could the wording be changed to something like "a log_max_* FW capability
of up to 8 bits"?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261103163949.1554-1-yishaih%40nvidia.com