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.
