Re: [PATCH rdma-next 07/23] RDMA/mlx5: Derive mlx5_ib_adversarial_mode global from mlx5_core adversarial API

[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 does not describe the code correctly.

--

RDMA/mlx5: Derive mlx5_ib_adversarial_mode global from mlx5_core adversarial API

This commit adds a global bool mlx5_ib_adversarial_mode to the mlx5_ib
driver. mlx5_ib_init() sets it from mlx5_is_adversarial(). The flag is
declared extern in mlx5_ib.h so that other files in the driver can read it.

> Use the mlx5_core mlx5_is_adversarial() exported API to set a
> module-level static bool mlx5_ib_adversarial_mode at init time,
> instead of a per-device bit field. This avoids propagating the flag
> through every mlx5_ib_dev pointer and makes the module-wide policy
> clear at the call sites.

[Severity: Low]
Is "static" the right word here? The patch adds a non-static global in
drivers/infiniband/hw/mlx5/main.c:

    bool mlx5_ib_adversarial_mode;

and makes it visible to the rest of the driver in
drivers/infiniband/hw/mlx5/mlx5_ib.h:

    extern bool mlx5_ib_adversarial_mode;

Later in the series the variable stays non-static, and umr.c and cq.c
read it. That is why it can't be static.

The text "instead of a per-device bit field" also seems to point at
something that isn't in the tree. No adversarial field exists under
drivers/infiniband/ before this patch, and the patch only adds lines. Is
this a leftover from an earlier, unmerged version of the series?

Could the message instead say that the patch adds a driver-wide global,
shared through mlx5_ib.h, that caches mlx5_is_adversarial() in
mlx5_ib_init()?

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