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

["John Daley (johndale)" <johndale@cisco.com>]

Got it, thanks Yongseok for the clarification. I may have sent it twice by accident. 
-john

> -----Original Message-----
> From: Yongseok Koh <yskoh@mellanox.com>
> Sent: Thursday, October 04, 2018 4:40 PM
> To: John Daley (johndale) <johndale@cisco.com>
> Cc: johnda888@gmail.com; dpdk stable <stable@dpdk.org>; Hyong Youb Kim
> (hyonkim) <hyonkim@cisco.com>
> Subject: Re: [dpdk-stable] [PATCH 1/3] net/enic: fix flow API memory leak
> 
> 
> > On Oct 4, 2018, at 3:03 PM, John Daley (johndale) <johndale@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%2Fpat
> >
> ches.dpdk.org%2Fpatch%2F45545%2F&amp;data=02%7C01%7Cyskoh%40me
> llanox.c
> >
> om%7Cb5541c8c6a2f4da3a1b908d62a454896%7Ca652971c7d2e4d9ba6a4d1
> 49256f46
> >
> 1b%7C0%7C0%7C636742874397325810&amp;sdata=wBWZ13CGeDZB3dnm%
> 2Bv4fXivc%2
> > BRQGRCpotawCQ3oE6PU%3D&amp;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@dpdk.org with the tag (Cc: stable@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@dpdk.org without dev@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@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@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@mellanox.com>
> >> Sent: Thursday, October 04, 2018 2:36 PM
> >> To: John Daley (johndale) <johndale@cisco.com>
> >> Cc: johnda888@gmail.com; dpdk stable <stable@dpdk.org>; Hyong Youb
> >> Kim
> >> (hyonkim) <hyonkim@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@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@dpdk.org
> >>>
> >>> Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
> >>> Reviewed-by: John Daley <johndale@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
> >>>
> >