From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4D9EDA0C41; Tue, 22 Jun 2021 09:24:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD3174003F; Tue, 22 Jun 2021 09:24:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id EAA4D4003C for ; Tue, 22 Jun 2021 09:24:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624346667; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+PaDoTGfK8uR+/Trj6Djg9+TY3ylHk5YCzn1LaxUYbE=; b=dyHZJ/ue0a2Nr5qa4RB9SP2KgGIt0FokGQVMzvt6uV3N8MZFZNXcZrO+KWgP7aVs9UeLRg i9Sg8iw35DnN+jSFC8BPIrETgvghZXxQCng19GbsY4AoKicJrO1wqNWbOrdhLMJwhLx7FE /bsu0fKjenQSwRBGMbYa1BfrFBEcbR0= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-456-VIu6GwVIPRyJNuM7rBVRCg-1; Tue, 22 Jun 2021 03:24:26 -0400 X-MC-Unique: VIu6GwVIPRyJNuM7rBVRCg-1 Received: by mail-vs1-f71.google.com with SMTP id y129-20020a677d870000b029026b5893c4aaso6424302vsc.4 for ; Tue, 22 Jun 2021 00:24:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+PaDoTGfK8uR+/Trj6Djg9+TY3ylHk5YCzn1LaxUYbE=; b=S6mxK7z1cQCXaH+d+Pmi16HjD3AguT/NfgTrJjtiUTmG5NdYn82SI/irm2uchMvDky GA35dXjkVouUQdog48Drr6vCo1JJSsdr+FeWKvYAicS/n5TlzPnq39AunBpJlYj/DHkM F0eHcouB5Njw+kU/fve4ICJ1I3E0Rs/TjfTEHdBy43nco9oRzgxWTTx2s693jzFCrQ9j AlUxavVxak4Y5+zbO7eBSOO15fDDeTuSmaqnaoUf0nX4wbfpAOCiso7DG8TYkHFeL+mt OiOncpAL4EwZ4+8AN+K5OlTWCPTpRabNqfzqfiikH8MMGpIRWLMC7cpujy84ieN5P4ZR h37w== X-Gm-Message-State: AOAM532mFg+fxcrmpFmz2Mibr770m/vyodTcDGBLxI/5w+6HqOvFbmuW 9VSK8/621YgnVVL+Ir5OCM4NkwRtWqPaScA+5L2UrhMwOSBtwRUWtTfHQYZz5HezYESa+6aJTjs KHaFIkio5CuCSgiYwI5s= X-Received: by 2002:a05:6102:38ca:: with SMTP id k10mr8769045vst.17.1624346665887; Tue, 22 Jun 2021 00:24:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHYfoFUwnxDHXFIPhRbShM80ssc1GqXvd537xZlocT8mM98Q9nRzqCpoFUXqOQQ8wr2l9OaCHwUYWcL+Bigns= X-Received: by 2002:a05:6102:38ca:: with SMTP id k10mr8769039vst.17.1624346665727; Tue, 22 Jun 2021 00:24:25 -0700 (PDT) MIME-Version: 1.0 References: <20210616195724.366103-1-ohilyard@iol.unh.edu> In-Reply-To: <20210616195724.366103-1-ohilyard@iol.unh.edu> From: David Marchand Date: Tue, 22 Jun 2021 09:24:14 +0200 Message-ID: To: Owen Hilyard , "Iremonger, Bernard" , "Yigit, Ferruh" Cc: dev Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] lib/flow_classify: fix leaking rules on delete X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jun 16, 2021 at 9:57 PM wrote: > > From: Owen Hilyard > > 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 > --- > 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. The same is done out of the loop which means this function returns -EINVAL and frees the rule in this case too. Bernard, Ferruh, can you review please? Thanks! -- David Marchand