Re: [PATCH rdma-next 23/23] RDMA/mlx5: Advertise adversarial mode via ib_device::adversarial_mode

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The series is not bisectable on confidential-computing (CoCo)
  guests.
- [Low] The commit message understates what this one line does.

--

RDMA/mlx5: Advertise adversarial mode via ib_device::adversarial_mode

This commit sets ib_device::adversarial_mode from the
mlx5_ib_adversarial_mode global in mlx5_ib_stage_caps_init(). The uverbs
core can then report adversarial mode to rdma-core and only let
adversarial-mode-aware userspace open a context on the device.

> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> index ace4cdc95c9da..f8af90941b53d 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -4778,6 +4778,7 @@ static int mlx5_ib_stage_caps_init(struct mlx5_ib_dev *dev)
>  	}
>  
>  	dev->ib_dev.use_cq_dim = true;
> +	dev->ib_dev.adversarial_mode = mlx5_ib_adversarial_mode;

[Severity: Medium]
Can the series still be bisected on CoCo guests when this assignment
comes last?

An earlier patch, "RDMA/mlx5: Derive mlx5_ib_adversarial_mode global from
mlx5_core adversarial API", sets the global in mlx5_ib_init():

    mlx5_ib_adversarial_mode = mlx5_is_adversarial();

This comes from cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT), so it is true
on any SEV-SNP/TDX guest.

Next, "RDMA/mlx5: Block generic CQ poll path in adversarial mode" adds
this to mlx5_poll_one():

    if (unlikely(mlx5_ib_adversarial_mode))
        return -EOPNOTSUPP;

That patch says this is safe because kernel ULPs don't bind to the device.

However, kernel ULPs only stop binding once ib_device_check_mandatory()
sees the core flag:

    if (device->adversarial_mode)
        device->kverbs_provider = false;

mlx5 doesn't set ib_dev.adversarial_mode until this commit.

That leaves a window from the CQ poll blocking patch up to "RDMA/core:
Report and enforce adversarial mode via GET_CONTEXT". In that window,
kverbs_provider stays true for mlx5 on a CoCo guest.

add_client_context() then binds MAD, CM, rdma_cm, IPoIB, SRP, iSER,
NVMe-oF and the other clients. Their CQs use mlx5_poll_one():

mlx5_ib_poll_cq()
  cq->poll_one() == mlx5_poll_one()
    returns -EOPNOTSUPP

mlx5_ib_poll_cq() stops at the first non-zero return, so it always reports
0 completions. Wouldn't MAD sends time out, the IPoIB TX ring fill up, and
NVMe-oF/SRP I/O hang in those intermediate commits?

In the same window, legacy rdma-core would still get contexts, and uverbs
POLL_CQ would always come back empty.

Could this assignment move into the patch that enables the driver-side
mode? Another option is to place it right after "RDMA/core: Suppress
kverbs_provider for adversarial_mode devices", before any hardening patch
that changes behaviour. Either way, every commit in the series would keep
working.

[Severity: Low]
This isn't a bug, but the commit message only says:

    Set ib_device::adversarial_mode during capability init so that the
    uverbs core layer can report adversarial mode to rdma-core and enforce
    that only adversarial-mode-aware userspace opens a context on this
    device.

In practice, this line turns on the full adversarial policy for every
mlx5 ib_device on a CC_ATTR_GUEST_MEM_ENCRYPT guest. The pf, raw_eth/rep
and plane profiles all run MLX5_IB_STAGE_CAPS.

With the flag set, ib_device_check_mandatory() clears kverbs_provider.
add_client_context() then skips every client that lacks no_kverbs_req:

    if (!device->kverbs_provider && !client->no_kverbs_req)
        return 0;

Only uverbs has no_kverbs_req. As a result, MAD, ib_umad, IB CM, SA,
rdma_cm, IPoIB, SRP, iSER, NVMe-oF, NFS/RDMA, RDS and SMC-R no longer
bind.

Because cma and SA never bind, librdmacm users going through ucma can't
use the device either, even if they are adversarial-aware.

Unmodified rdma-core also gets -EPERM, both from GET_CONTEXT and from the
legacy write() path.

There is no opt-out, since the decision comes only from
cc_platform_has(). Other patches in the series say this is intended, but
this commit is where it takes effect for mlx5.

Could the commit message say that, once this is applied, kernel ULPs and
rdma_cm-based userspace stop working on mlx5 in CoCo guests?

>  
>  	return 0;
>

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