[dpdk-stable] [PATCH 1/3] net/enic: fix flow API memory leak

[Yongseok Koh]

> On Oct 4, 2018, at 3:03 PM, John Daley (johndale) <johndale at cisco.com> wrote:
> 
> Hi Yongseok,
> 
> It should go into 17.11 and hopefully 18.02, 18.05, 18.08 eventually.
> 
> Not sure what  you mean when you say it was only for stable releases. It was submitted to dev@ with the Cc: stable@ in the commit. The patch is here: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F45545%2F&data=02%7C01%7Cyskoh%40mellanox.com%7Cb5541c8c6a2f4da3a1b908d62a454896%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636742874397325810&sdata=wBWZ13CGeDZB3dnm%2Bv4fXivc%2BRQGRCpotawCQ3oE6PU%3D&reserved=0
> 
> When cc'ing stable in dev@ submissions, should we generally follow up with an email to stable@ to indicate which stable branches to target? If so, should we update the instructions in the contributors guide (section 6.4), or did I miss where that process is documented?

If you send out a patch to dev at dpdk.org with the tag (Cc: stable at dpdk.org), the
patch will automatically be queued for stable branches. But the reason why I
asked the question was this specific one has been sent to stable at dpdk.org
without dev at dpdk.org. It looks you've sent the same patch twice?

Summary.

1) If you want to fix a bug in the current upstream (dpdk/master), send the fix
to dev at dpdk.org with the stable cc tag, then it will be automatically queued to
be backported to a stable branch if the bug is in the stable branch. If you
don't think backporting is necessary, you don't need to add the stable cc tag.
Then, nothing will happen.

2) If you want to fix a bug and the bug exists only in a stable branch, not in
the master branch, then you should send it only to stable at dpdk.org with a
prefix. Please refer to "5.11.1. Backporting patches for Stable Releases" in
the guide.  E.g.,
	git send-email --subject-prefix='PATCH 16.11' ...
If the bug exists in multiple stable branches, you should send it multiple times.


Thanks,
Yongseok

> Thanks,
> John
> 
>> -----Original Message-----
>> From: Yongseok Koh <yskoh at mellanox.com>
>> Sent: Thursday, October 04, 2018 2:36 PM
>> To: John Daley (johndale) <johndale at cisco.com>
>> Cc: johnda888 at gmail.com; dpdk stable <stable at dpdk.org>; Hyong Youb Kim
>> (hyonkim) <hyonkim at cisco.com>
>> Subject: Re: [dpdk-stable] [PATCH 1/3] net/enic: fix flow API memory leak
>> 
>> 
>>> On Sep 27, 2018, at 6:51 PM, John Daley <johndale at cisco.com> wrote:
>>> 
>>> rte_flow structures were not being freed when destroyed or flushed.
>>> 
>>> Fixes: 6ced137607d0 ("net/enic: flow API for NICs with advanced
>>> filters enabled")
>>> Cc: stable at dpdk.org
>>> 
>>> Signed-off-by: Hyong Youb Kim <hyonkim at cisco.com>
>>> Reviewed-by: John Daley <johndale at cisco.com>
>>> ---
>> 
>> Hi,
>> 
>> Is this patch only for stable releases? If so, which one? Or was dev@ absent
>> by mistake?
>> 
>> 
>> Thanks,
>> Yongseok
>> 
>>> drivers/net/enic/enic_flow.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/drivers/net/enic/enic_flow.c
>>> b/drivers/net/enic/enic_flow.c index 0cf04aefd..9b612f1d5 100644
>>> --- a/drivers/net/enic/enic_flow.c
>>> +++ b/drivers/net/enic/enic_flow.c
>>> @@ -1532,6 +1532,7 @@ enic_flow_destroy(struct rte_eth_dev *dev,
>> struct rte_flow *flow,
>>> 	enic_flow_del_filter(enic, flow->enic_filter_id, error);
>>> 	LIST_REMOVE(flow, next);
>>> 	rte_spinlock_unlock(&enic->flows_lock);
>>> +	rte_free(flow);
>>> 	return 0;
>>> }
>>> 
>>> @@ -1555,6 +1556,7 @@ enic_flow_flush(struct rte_eth_dev *dev, struct
>> rte_flow_error *error)
>>> 		flow = LIST_FIRST(&enic->flows);
>>> 		enic_flow_del_filter(enic, flow->enic_filter_id, error);
>>> 		LIST_REMOVE(flow, next);
>>> +		rte_free(flow);
>>> 	}
>>> 	rte_spinlock_unlock(&enic->flows_lock);
>>> 	return 0;
>>> --
>>> 2.16.2
>>> 
>