On 5/5/2020 9:09 AM, Ferruh Yigit wrote:
> On 5/1/2020 5:19 PM, Stephen Hemminger wrote:
>> On Fri, 1 May 2020 17:01:40 +0100
>> Ferruh Yigit <ferruh.yi...@intel.com> wrote:
>>
>>> On 4/27/2020 10:39 PM, Stephen Hemminger wrote:
>>>> The TAP driver does not initialize all the elements of the rte_flow
>>>> structure. This can lead to crash in rte_flow_destroy.
>>>>
>>>> (gdb) where
>>>> flow=0x100e99280, error=0x0)
>>>> at drivers/net/tap/tap_flow.c:1514
>>>>
>>>> (gdb) p remote_flow
>>>> $1 = (struct rte_flow *) 0x6b6b6b6b6b6b6b6b
>>>>
>>>> Which is here:
>>>> static int
>>>> tap_flow_destroy_pmd(struct pmd_internals *pmd,
>>>> struct rte_flow *flow,
>>>> struct rte_flow_error *error)
>>>> {
>>>> struct rte_flow *remote_flow = flow->remote_flow;
>>>> ...
>>>> if (remote_flow) {
>>>> remote_flow->msg.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>>>>
>>>> Simplest fix is to use rte_zmalloc() so remote_flow and other fields
>>>> are always set at zero.
>>>
>>> Both 'rte_malloc' & 'rte_zmalloc' should be zeroing the allocated memory,
>>> unless
>>> MALLOC_DEBUG config option set [1], if this is not the case the issue can be
>>> still valid after this change.
>>
>> Malloc debug poisons memory to find bugs like this.
>>
>
> Fair enough, if that is the intention use 'rte_zmalloc' to clarify it.
>
> Reviewed-by: Ferruh Yigit <ferruh.yi...@intel.com>
>
Applied to dpdk-next-net/master, thanks.
