[ovs-discuss] openvswitch2.3.0 kernel crash

Jesse Gross jesse at kernel.org
Thu Sep 8 16:35:41 UTC 2016


There wasn't a direct followup but the problem was effectively
addressed by the lightweight tunnel changes and I don't believe that
it can happen at this point. Those changes were introduced in OVS 2.5.

I think it's unlikely that we will do another release off of the 2.3.x
series at this point so I'm not sure there is much more to do with
regards to backporting.

On Thu, Sep 8, 2016 at 4:34 AM, D. Herrendoerfer
<d.herrendoerfer at herrendoerfer.name> wrote:
> Hello,
>
> was this issue ever followed up ?
> I see no corresponding changes in the kernel nor anywhere else,
> but I appear to have hit the same kernel crash.
>
> I see it on RHEL7.2 with openvswitch-2.3.2.
>
> Cheers,
>
> Dirk
>
>>Hi jesse,
>>
>>I will submit this patch to upstream then backport it to OVS
>>
>>
>>
>>
>>
>>At 2015-12-22 01:20:11, "Jesse Gross" <jesse at kernel.org> wrote:
>>>On Sun, Dec 20, 2015 at 9:29 PM, wenxu <wenx05124561 at 163.com> wrote:
>>>> Hi all,
>>>>
>>>> I meet a crash problem in kernel with openvswitch2.3.0
>>>[...]
>>>> It crashed in ovs_flow_extract with _skb_pull the src&dst mac address
>>>> (BUG_ON(skb->len < skb->data_len);)
>>>> int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct
>>>> sw_flow_key
>>>> *key)
>>>> {
>>>>     .....
>>>>     __skb_pull(skb, 2 * ETH_ALEN);
>>>>     .....
>>>> }
>>>
>>>Thanks for tracking this down. I agree with your analysis.
>>>
>>>> I think ovs should check this mess situation in two ways.
>>>> 1. check the tpi->proto
>>>
>>>Your solution looks right to me but we also need to fix the upstream
>>>Linux kernel, which has the same issue. Can you please submit a patch
>>>to fix it there and then backport it to OVS? I should also point out
>>>that this does not affect the current version of either OVS or Linux
>>>as the code has changed and is not vulnerable to this. However, the
>>>older versions are still in use and being maintained.
>>>
>>>> 2. add pskb_may_pull before pull like ip_gre did
>>>
>>>I don't believe that this is necessary if we have #1. GRE does this
>>>for the Ethernet header if the protocol is set to TEB. Other Ethernet
>>>drivers are also required to enforce this invariant.
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>



More information about the discuss mailing list