On Mon, Dec 22, 2014 at 1:30 PM, Jesse Gross <je...@nicira.com> wrote:
> On Mon, Dec 22, 2014 at 3:08 PM, Pravin Shelar <pshe...@nicira.com> wrote:
>> On Mon, Dec 22, 2014 at 11:56 AM, Jesse Gross <je...@nicira.com> wrote:
>>> On Mon, Dec 22, 2014 at 1:25 PM, Pravin Shelar <pshe...@nicira.com> wrote:
>>>> On Sun, Dec 21, 2014 at 9:39 PM, Jesse Gross <je...@nicira.com> wrote:
>>>>> On Sun, Dec 21, 2014 at 6:17 PM, Jesse Gross <je...@nicira.com> wrote:
>>>>>> On Fri, Dec 19, 2014 at 7:25 PM, Pravin B Shelar <pshe...@nicira.com> 
>>>>>> wrote:
>>>>>>> Today vport-send has complex error handling because it involves
>>>>>>> freeing skb and updating stats depending on return value from
>>>>>>> vport send implementation.
>>>>>>> This can be simplified by delegating responsibility of freeing
>>>>>>> skb to the vport implementation for all cases. So that
>>>>>>> vport-send needs just update stats.
>>>>>>>
>>>>>>> Signed-off-by: Pravin B Shelar <pshe...@nicira.com>
>>>>>>
>>>>>> It's somewhat non-obvious to me that handle_offloads should free the
>>>>>> skb in the event of an error. It seems like this introduces more
>>>>>> complexity to this patch as well.
>>>>>>
>>>>>> As an example of the problem, I think that the previous patch
>>>>>> introduces a double free in the non-compat case. This is because it
>>>>>> updates the skb freeing for the compat code in handle_offloads() but
>>>>>> the equivalent update to the non-compat code isn't made until this
>>>>>> patch.
>>>>>
>>>>> I now see that the upstream iptunnel_handle_offloads() also frees the
>>>>> skb on error but it seems like this has introduced some errors as
>>>>> well. It looks like several tunnel protocols continue using the skb
>>>>> after calling handle_offloads without any kind of check.
>>>>
>>>> right, Thats the reason.
>>>> I am not sure which one still missing the check, Can you point me to
>>>> them? I have fixed GRE already.
>>>
>>> It looks like Geneve is the only one at this point - I thought that
>>> VXLAN had a similar problem but I was looking at an old version of the
>>> code.
>>
>> OK, you are looking at upstream Geneve code.
>
> Yes - I was referring to the upstream tunnel implementations before.
> That's what I meant, it seemed like these bugs were somewhat
> pervasive. Since almost all of the implementations have been fixed, I
> guess it makes sense to just leave it as is and mirror the upstream
> into the compat code. Will you send a patch for Geneve upstream as
> part of this?

I also want to mirror upstream code for compat. the patch series is
first step. I will send vport_send() change and Geneve fix upstream.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to