datapath-windows:adjust Offset when processing packet in POP_VLAN action
In one typical setup, on the Windows VM running OVS Windows Kernel, a Geneva
packet with 8021.q VLAN tag is received. Then it may do POP_VLAN action
processing in Actions.c, if the packet does not have Ieee8021QNetBufferListInfo
in the oob of the packet, it will be processed by function OvsPopVlanInPktBuf().
In the function it will go on remove VLAN header present in the nbl, but related
layers is never readjusted for the offset value at this moment. As a result, it
will cause function OvsValidateIPChecksum drop the packet.
This is a backport of commit 1bddcb5dc (ofproto-dpif-xlate: Fix
bug that may leak ofproto_flow_mod) from branch-2.8. That commit
won't cherry-pick cleanly onto branch-2.7 as the addition of the
learn limit in 2.8 changed xlate_learn_action() a lot.
Neutron ml2/ovs uses a learn action to learn from tunnels and the
leak can grow to tens of GB after several months.
Valgrind after 10K up calls:
575,680 bytes in 8,995 blocks are definitely lost in loss record 373 of 373
malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
xmalloc (util.c:112)
miniflow_alloc (flow.c:2500)
minimatch_init (match.c:1387)
rule_criteria_init (ofproto.c:4060)
modify_flow_init_strict (ofproto.c:5431)
ofproto_flow_mod_init (ofproto.c:7432)
ofproto_flow_mod_init_for_learn (ofproto.c:4988)
xlate_learn_action (ofproto-dpif-xlate.c:4417)
do_xlate_actions (ofproto-dpif-xlate.c:5359)
xlate_recursively (ofproto-dpif-xlate.c:3453)
xlate_table_action (ofproto-dpif-xlate.c:3520)
xlate_ofpact_resubmit (ofproto-dpif-xlate.c:3810)
do_xlate_actions (ofproto-dpif-xlate.c:5248)
xlate_recursively (ofproto-dpif-xlate.c:3453)
xlate_table_action (ofproto-dpif-xlate.c:3520)
xlate_ofpact_resubmit (ofproto-dpif-xlate.c:3810)
do_xlate_actions (ofproto-dpif-xlate.c:5248)
xlate_actions (ofproto-dpif-xlate.c:5962)
upcall_xlate (ofproto-dpif-upcall.c:1132)
process_upcall (ofproto-dpif-upcall.c:1269)
recv_upcalls.isra.20 (ofproto-dpif-upcall.c:824)
udpif_upcall_handler (ofproto-dpif-upcall.c:746)
ovsthread_wrapper (ovs-thread.c:348)
start_thread (pthread_create.c:333)
clone (clone.S:109
ad0d22f...
by
Flavio Leitner <email address hidden>
flow: Support extra padding length.
Although not required, padding can be optionally added until
the packet length is MTU bytes. A packet with extra padding
currently fails sanity checks.
A packet that contains multiple instances of certain TLVs will cause
lldpd to continually allocate memory and leak the old memory. As an
example, multiple instances of system name TLV will cause old values
to be dropped by the decoding routine.
