From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
To: David Marchand <david.marchand@redhat.com>,
Owen Hilyard <ohilyard@iol.unh.edu>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib/flow_classify: fix leaking rules on delete
Date: Tue, 22 Jun 2021 11:59:33 +0000 [thread overview]
Message-ID: <DM6PR11MB2890370DA584B4165D4C1D78EF099@DM6PR11MB2890.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8wpct2G_ZHWgnirA9x40AUGSCkAs9+WcBsq9cFWutbVcw@mail.gmail.com>
Hi David, Owen,
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Tuesday, June 22, 2021 8:24 AM
> To: Owen Hilyard <ohilyard@iol.unh.edu>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev <dev@dpdk.org>
> Subject: Re: [PATCH] lib/flow_classify: fix leaking rules on delete
>
> On Wed, Jun 16, 2021 at 9:57 PM <ohilyard@iol.unh.edu> wrote:
> >
> > From: Owen Hilyard <ohilyard@iol.unh.edu>
> >
> > Rules in a classify table were not freed if the table had a delete
> > function.
> >
> > Fixes: be41ac2a3 ("flow_classify: introduce flow classify library")
> Cc: stable@dpdk.org
>
> >
> > Signed-off-by: Owen Hilyard <ohilyard@iol.unh.edu>
> > ---
> > lib/flow_classify/rte_flow_classify.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/flow_classify/rte_flow_classify.c
> > b/lib/flow_classify/rte_flow_classify.c
> > index f125267e8..06aed3b70 100644
> > --- a/lib/flow_classify/rte_flow_classify.c
> > +++ b/lib/flow_classify/rte_flow_classify.c
> > @@ -579,7 +579,7 @@ rte_flow_classify_table_entry_delete(struct
> rte_flow_classifier *cls,
> > &rule->u.key.key_del,
> > &rule->key_found,
> > &rule->entry);
> > -
> > + free(rule);
> > return ret;
> > }
> > }
>
> I find it strange to free the rule regardless of the result of the
> f_delete() op.
I agree the result of the f_delete() op should be checked before freeing the rule.
> The same is done out of the loop which means this function returns -EINVAL
> and frees the rule in this case too.
The free() outside the loop at line 587 does not make sense to me now and should be removed.
>
> Bernard, Ferruh, can you review please?
>
> Thanks!
>
>
> --
> David Marchand
Regards,
Bernard.
next prev parent reply other threads:[~2021-06-22 11:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 19:57 ohilyard
2021-06-22 7:24 ` David Marchand
2021-06-22 11:59 ` Iremonger, Bernard [this message]
2021-06-23 17:07 ` [dpdk-dev] [PATCH v2] flow_classify: " ohilyard
2021-06-24 8:43 ` Iremonger, Bernard
2021-06-24 9:12 ` David Marchand
2021-06-24 13:21 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM6PR11MB2890370DA584B4165D4C1D78EF099@DM6PR11MB2890.namprd11.prod.outlook.com \
--to=bernard.iremonger@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=ohilyard@iol.unh.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).