[PATCH 22.11] net/mlx5: fix async flow create error handling

[Luca Boccassi]

On Wed, 3 Apr 2024 at 14:50, Dariusz Sosnowski <dsosnowski at nvidia.com> wrote:
>
> > -----Original Message-----
> > From: Luca Boccassi <bluca at debian.org>
> > Sent: Wednesday, April 3, 2024 13:16
> > To: Dariusz Sosnowski <dsosnowski at nvidia.com>; Matan Azrad
> > <matan at nvidia.com>; Slava Ovsiienko <viacheslavo at nvidia.com>; Suanming
> > Mou <suanmingm at nvidia.com>
> > Cc: stable at dpdk.org; Ori Kam <orika at nvidia.com>
> > Subject: Re: [PATCH 22.11] net/mlx5: fix async flow create error handling
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, 2024-04-03 at 10:38 +0200, Dariusz Sosnowski wrote:
> > > [ upstream commit 5ecc8df4fad3411a53c20406f99b59dc736a6d1e ]
> > >
> > > Whenever processing of asynchronous flow rule create operation failed,
> > > but after some dynamic flow actions had already been allocated, these
> > > actions were not freed during error handling flow.
> > > That behavior lead to leaks e.g., RSS/QUEUE action objects were leaked
> > > which triggered assertions during device cleanup.
> > >
> > > This patch adds flow rule cleanup handling in case of an error during
> > > async flow rule creation.
> > >
> > > Fixes: 3a2f674b6aa8 ("net/mlx5: add queue and RSS HW steering action")
> > > Cc: stable at dpdk.org
> > >
> > > Signed-off-by: Dariusz Sosnowski <dsosnowski at nvidia.com>
> > > Acked-by: Ori Kam <orika at nvidia.com>
> > >
> >
> > This patch does not apply on stable/22.11, how was it tested?
>
> The backports were tested today by applying on 22.11 branch on git at github.com:bluca/dpdk-stable.git
>
> Could you please try applying mlx5 patches sent by me in the following order?
>
> 1. "net/mlx5: fix flow configure validation"
> 2. "net/mlx5: fix rollback on failed flow configure"
> 3. "net/mlx5: fix async flow create error handling"
>
> There might be some conflicts between these patches, maybe that's the reason for failure. I'm sorry about not mentioning this.
> I retested applying them on commit efe1d783f474, in that order and it applied correctly on my side.

Thanks, that works, my email client showed me the 3rd one as the first
mail, so when downloading the mbox with all 3 it failed. Next time
please use a series so that you know the order you meant is the one we
see too.