Re: [PATCH v13 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr

On Fri, Jul 31, 2026 at 2:48=E2=80=AFPM <[email protected]> wrote:
...
> [Severity: High]
> This is a pre-existing issue, but this patch introduces a new, heavily-ex=
ercised
> reachable path for it.
>
> Does mlx5_st_dealloc_index() leak the mlx5_st_idx_data struct when erasin=
g it
> from the xarray?
>
> When a steering tag's reference count drops to zero, the entry is removed=
 via
> xa_erase():
>
> drivers/net/ethernet/mellanox/mlx5/core/lib/st.c:mlx5_st_dealloc_index() =
{
>     ...
>         if (refcount_dec_and_test(&idx_data->usecount)) {
>                 xa_erase(&st->idx_xa, st_index);
>                 /* We leave PCI config space as was before, no mkey will =
refer to it */
>         }
>     ...
> }
>
> However, the underlying idx_data pointer is not freed with kfree(idx_data=
).
>
> Because the next time the same tag is requested, a new struct is allocate=
d via
> kzalloc_obj() in mlx5_st_alloc_index_by_tag(), won't repeated allocations=
 and
> deallocations lead to an unbounded kernel memory leak?
>

This is the leak fixed by "net/mlx5: free mlx5_st_idx_data on final
dealloc" (df6134b527a8). Sashiko appears to have applied the series to
a tree predating that commit.