Re: [PATCH rdma-rc] RDMA/mlx5: Fix DevX umem page size truncation for pages >= 4G

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Nov 03, 2026 at 03:28:04PM +0100, 0z5a wrote:
> From: Dezhen Lu <dezhen.lu@student.uni-tuebingen.de>
> 
> devx_umem_find_best_pgsize() computes the page size in an unsigned long
> but returns it as unsigned int, and devx_umem_reg_cmd_alloc() stores it
> in an unsigned int. When the DMA mapping of the umem is contiguous and
> aligned to 4 GiB or more, and the umem length is a multiple of that
> size, ib_umem_find_best_pgoff() selects a page size >= 2^32. Since the
> value is a power of two, the truncation turns it into 0 and the
> registration fails with -EINVAL.
> 
> The umem log_page_size field is 5 bits wide on top of
> MLX5_ADAPTER_PAGE_SHIFT, so the command can encode these page sizes.
> 
> Seen on two GH200 nodes (ConnectX-7, firmware 32.38.3056 and
> 32.43.1014) with a dma-buf exported from cudaMalloc memory: registering
> 4 GiB or 8 GiB umems at 4 GiB-aligned offsets of the dma-buf fails with
> EINVAL every time, while 2 GiB umems at the same offsets and
> ibv_reg_dmabuf_mr() of the same ranges succeed. Restricting the user
> pgsz_bitmap to <= 2 GiB makes all of them succeed.
> 
> Other large physically contiguous buffers, such as a 16 GiB hugetlb
> page on an arm64 kernel with 64K base pages, should hit the same path.
> 
> Use unsigned long for the page size, as commit f0c2427412b4
> ("RDMA/mlx5: Fix page_size variable overflow") already did for the MR
> paths.
> 
> The bug was found by an AI coding assistant (Claude Opus 5.5, Anthropic)
> during an audit of 32-bit truncations of page sizes and offsets in
> drivers/infiniband/core and drivers/infiniband/hw/mlx5. The assistant
> also wrote the reproducer and this patch. The reproducer was run on the
> GH200 nodes described above.
> 
> Fixes: 7610ab57de56 ("RDMA/mlx5: Allow larger pages in DevX umem")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dezhen Lu <dezhen.lu@student.uni-tuebingen.de>
> ---

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

>     - So I have not verified that CREATE_UMEM accepts log_page_size values
>       for pages >= 4 GiB. If it does not, capping pgsz_bitmap at 2^31 in
>       devx_umem_find_best_pgsize() is the alternative fix.

It is userspace's problem to provide a correct bitmap in
MLX5_IB_ATTR_DEVX_UMEM_REG_PGSZ_BITMAP
for whatever it is doing. FW can reject large sizes outside what it
supports if userspace sends the incorrect bitmap.

Jason