[ovs-discuss] Kernel Panic with Openvswitch 2.7.3

[Pravin Shelar]

On Thu, May 31, 2018 at 7:10 AM, Johannes Erdfelt <johannes at erdfelt.com> wrote:
> On Wed, May 30, 2018, Pravin Shelar <pshelar at ovn.org> wrote:
>> I am not sure why are you seeing frag_list for large UDP packet, STT
>> would linearize such UDP packet.
>> https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L299
>> Can you check why are you seeing frag_list after STT decapsulation?
>
> We are. The skb dump in my original post was from well past
> decapsulation.
>
>> Is SKIP_ZERO_COPY defined for the STT build?
>
> Yes. It seems because we have CONFIG_SLUB enabled for our kernel:
>
> https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L52
>
>> May be the assumption in try_to_segment() is not true for skb
>> generated by certain NICs.
>> ref: https://github.com/openvswitch/ovs/blob/06db81ccfe6d4c779de2ca73033abd7020db419b/datapath/linux/compat/stt.c#L566
>> In that case we need to fix STT.
>
> In our case since it's a large GSO UDP packet, then ->next is NULL. This
> would cause coalesce_skb() to be skipped:
>
> https://github.com/openvswitch/ovs/blob/branch-2.7/datapath/linux/compat/stt.c#L1456
>
> Then try_to_segment is skipped because SKIP_ZERO_COPY is defined.
>
> While the comment here appears to be true:
>
> https://github.com/openvswitch/ovs/blob/branch-2.7/datapath/linux/compat/stt.c#L563
>
> It appears it doesn't take into account NICs may generate a frag_list?
>
> I'm not a networking expert, but as far as I can tell, the large skb
> from this solarflare NIC appears to be valid (uses frag_list).
>
> I'm not familiar with the OVS code to understand why the linearize is
> necessary. It seems like that would impact performance significantly.
>

solarflare NIC is generating valid skb.
But STT can combine multiple skb into single skb using fraglist and
skb list. Networking stack can not handle such skb. for example
skb_segment() does not handle skb with arbitrary geometry, ip-defrag
might have similar issues. OVS can forward such skb to networking
stack that causes the issue.
Therefore STT has to linearize such skb.