Re: [PATCH rdma-next 05/23] RDMA/mlx5: Reject QP transport types not enabled by FW capability

[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 the new rc/uc/ud checks in
  check_qp_type() (drivers/infiniband/hw/mlx5/qp.c) refuse 'a transport…

--

RDMA/mlx5: Reject QP transport types not enabled by FW capability

This commit makes check_qp_type() in drivers/infiniband/hw/mlx5/qp.c also
check the rc, uc and ud general capability bits. QP creation for RC, UC
and UD now returns -EOPNOTSUPP when the matching bit is clear. Before
this change, only XRC and DC were gated on capabilities.

> Check the rc, uc and ud capabilities as well, so that QP creation is
> refused for a transport the FW does not support.

[Severity: Low]
Could the commit message explain why this is needed and what userspace
will see after it?

As far as I can tell, the new lines in check_qp_type() are the first
readers of the rc, uc and ud bits anywhere in the tree. With trusted FW,
the change seems to only move a CREATE_QP failure from the FW into the
driver.

The visible effect seems to come from the earlier patch "net/mlx5: Add
capability filtering in adversarial mode". In caps_filter.c,
mlx5_adversarial_filter_general() clears cmd_hca_cap and then restores
only an allow-list of fields:

mlx5_adversarial_filter_general() {
    ...
    memset(dst, 0, MLX5_UN_SZ_BYTES(hca_cap_union));
    ...
    MLX5_HCA_CAP_ALLOW(cmd_hca_cap, rc);
    ...
}

rc is on that list, but ud, uc and xrc are not. In confidential computing
guests running in adversarial mode, every UD and UC QP request would now
fail in check_qp_type():

    case IB_QPT_UD:
        if (!MLX5_CAP_GEN(dev->mdev, ud))
            goto out;

Only RC, RAW_PACKET and the internal special QP types could still be
created. This affects userspace. It also affects kernel ULPs such as
IPoIB until the later patch "RDMA/core: Suppress kverbs_provider for
adversarial_mode devices".

The driver itself clears these bits by policy, so would it be clearer to
describe that as the purpose of this patch? Could the message also say
whether this is a bug fix (with a Fixes: tag) or hardening, so stable
backporters can decide?

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