On 1/30/2019 11:30 AM, Ferruh Yigit wrote:
> On 1/30/2019 1:08 AM, Qi Zhang wrote:
>> Fix potential memory leak due to kvlist not be freed.
>>
>> Fixes: 0d0dd2d9d8ff ("net/pcap: enable data path for secondary process")
>> Cc: sta...@dpdk.org
>>
>> Reported-by: Gage Eads
>> Signed-off-by: Qi Zhang
On 1/30/2019 1:08 AM, Qi Zhang wrote:
> Fix potential memory leak due to kvlist not be freed.
>
> Fixes: 0d0dd2d9d8ff ("net/pcap: enable data path for secondary process")
> Cc: sta...@dpdk.org
>
> Reported-by: Gage Eads
> Signed-off-by: Qi Zhang
Acked-by: Ferruh Yigit
Fix potential memory leak due to kvlist not be freed.
Fixes: 0d0dd2d9d8ff ("net/pcap: enable data path for secondary process")
Cc: sta...@dpdk.org
Reported-by: Gage Eads
Signed-off-by: Qi Zhang
---
drivers/net/pcap/rte_eth_pcap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On 11/6/2017 11:52 AM, Ferruh Yigit wrote:
> On 11/5/2017 9:24 AM, Stefan Baranoff wrote:
>> In open_single_tx_pcap there is a call to pcap_open_dead which calls
>> malloc to create and return a pcap_t. That object is never freed in
>> this case. Other places it is freed by passing it back similar
On 11/5/2017 9:24 AM, Stefan Baranoff wrote:
> In open_single_tx_pcap there is a call to pcap_open_dead which calls
> malloc to create and return a pcap_t. That object is never freed in
> this case. Other places it is freed by passing it back similar to the
> way the pcap_dumper_t is in this case.
In open_single_tx_pcap there is a call to pcap_open_dead which calls
malloc to create and return a pcap_t. That object is never freed in
this case. Other places it is freed by passing it back similar to the
way the pcap_dumper_t is in this case.
The pcap_t is only used to create the pcap_dumper_t
6 matches
Mail list logo