[PATCH] RDMA/mlx5: fix linking with CONFIG_INFINIBAND_USER_ACCESS=n

[PATCH] RDMA/mlx5: fix linking with CONFIG_INFINIBAND_USER_ACCESS=n

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The check for rdma_uattrs_has_raw_cap() is not possible if user
access is disabled:

ERROR: modpost: "rdma_uattrs_has_raw_cap" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!

Limit the check to configurations that have the option enabled
and instead assume the capability is not there otherwise.

From what I can tell, the UVERBS code in fs.c is not actually called
when INFINIBAND_USER_ACCESS is turned off, so this haz no effect
other than fixing the link error. A better change might be to not
build the code at all in that configuration, but I did not see
an obvious way to do that.

Fixes: 95a89ec304c3 ("RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If there is a better way of addressing the link failure, please just
treat this as a bug report
---
 drivers/infiniband/hw/mlx5/fs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/fs.c b/drivers/infiniband/hw/mlx5/fs.c
index bab2f58240c9..c1ec9aa1dfd3 100644
--- a/drivers/infiniband/hw/mlx5/fs.c
+++ b/drivers/infiniband/hw/mlx5/fs.c
@@ -2459,7 +2459,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
 	struct mlx5_ib_dev *dev;
 	u32 flags;
 
-	if (!rdma_uattrs_has_raw_cap(attrs))
+	if (!IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS) ||
+	    !rdma_uattrs_has_raw_cap(attrs))
 		return -EPERM;
 
 	fs_matcher = uverbs_attr_get_obj(attrs,
-- 
2.39.5

Re: [PATCH] RDMA/mlx5: fix linking with CONFIG_INFINIBAND_USER_ACCESS=n

[yanjun.zhu]

On 7/10/25 1:09 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The check for rdma_uattrs_has_raw_cap() is not possible if user
> access is disabled:
> 
> ERROR: modpost: "rdma_uattrs_has_raw_cap" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!

https://patchwork.kernel.org/project/linux-rdma/patch/72dee6b379bd709255a5d8e8010b576d50e47170.1751967071.git.leon@kernel.org/

The issue you described seems to be the same as the one discussed in the 
link above. Could you try applying the commit from that link and see if 
the problem still persists?

Yanjun.Zhu

> 
> Limit the check to configurations that have the option enabled
> and instead assume the capability is not there otherwise.
> 
>  From what I can tell, the UVERBS code in fs.c is not actually called
> when INFINIBAND_USER_ACCESS is turned off, so this haz no effect
> other than fixing the link error. A better change might be to not
> build the code at all in that configuration, but I did not see
> an obvious way to do that.
> 
> Fixes: 95a89ec304c3 ("RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> If there is a better way of addressing the link failure, please just
> treat this as a bug report
> ---
>   drivers/infiniband/hw/mlx5/fs.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/fs.c b/drivers/infiniband/hw/mlx5/fs.c
> index bab2f58240c9..c1ec9aa1dfd3 100644
> --- a/drivers/infiniband/hw/mlx5/fs.c
> +++ b/drivers/infiniband/hw/mlx5/fs.c
> @@ -2459,7 +2459,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
>   	struct mlx5_ib_dev *dev;
>   	u32 flags;
>   
> -	if (!rdma_uattrs_has_raw_cap(attrs))
> +	if (!IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS) ||
> +	    !rdma_uattrs_has_raw_cap(attrs))
>   		return -EPERM;
>   
>   	fs_matcher = uverbs_attr_get_obj(attrs,

Re: [PATCH] RDMA/mlx5: fix linking with CONFIG_INFINIBAND_USER_ACCESS=n

[Arnd Bergmann]

On Thu, Jul 10, 2025, at 22:12, yanjun.zhu wrote:
> On 7/10/25 1:09 AM, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> 
>> The check for rdma_uattrs_has_raw_cap() is not possible if user
>> access is disabled:
>> 
>> ERROR: modpost: "rdma_uattrs_has_raw_cap" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
>
> https://patchwork.kernel.org/project/linux-rdma/patch/72dee6b379bd709255a5d8e8010b576d50e47170.1751967071.git.leon@kernel.org/
>
> The issue you described seems to be the same as the one discussed in the 
> link above. Could you try applying the commit from that link and see if 
> the problem still persists?

That one looks fine, I'm sure it's sufficient without my patch.

    Arnd