Re: [PATCH v2] net/mlx5e: TC, fix internal port leak when a flow is reoffloaded

[Tariq Toukan <tariqt@nvidia.com>]

Hi,

For some reason, this V2 is threaded in the same mail-thread of V1.

On 08/11/2026 15:21, Wentao Liang wrote:
> For a flow originating from an OVS internal port,
> mlx5e_tc_add_fdb_flow() takes a reference on the internal port and stores
> it in the flow's esw attribute.
> 
> If the flow cannot be offloaded because the encap route is not available
> (-ENETUNREACH) on a multipath LAG setup, __mlx5e_add_fdb_flow() keeps the
> flow on the unready list instead of freeing it. When
> mlx5e_tc_reoffload_flows_work() retries, mlx5e_tc_add_fdb_flow() takes
> another reference and overwrites the stored pointer, so the previous
> reference is never dropped.
> 
Thanks for the report, the leak is real.

It is one case of a wider problem, though. A flow kept for re-offload 
holds on to whatever the failed attempt attached, and the next attempt 
attaches it again. Sashiko pointed at other cases on v1 [1]:

IMO we better fix this by releasing what the failed attempt attached 
before the flow is kept for re-offload. That covers the filter device's 
internal port as well, so the check here won't be needed.

We'll post the fix with your Reported-by. Unless you really want to post 
it yourself.

[1] 
https://lore.kernel.org/netdev/179405518707.994134.3869617957663198262@kernel.org/