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 PM <[email protected]> wrote:
...
> [Severity: High]
> This is a pre-existing issue, but this patch introduces a new, heavily-exercised
> reachable path for it.
>
> Does mlx5_st_dealloc_index() leak the mlx5_st_idx_data struct when erasing 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 allocated 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.