[ovs-git] [openvswitch/ovs] 8b496c: ofproto-dpif-xlate: Correctly decide whether trunc...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 8b496c72c782a1231806f6c9247730ebdc5a0a12
      https://github.com/openvswitch/ovs/commit/8b496c72c782a1231806f6c9247730ebdc5a0a12
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-12-08 (Fri, 08 Dec 2017)

  Changed paths:
    M ofproto/ofproto-dpif-xlate.c

  Log Message:
  -----------
  ofproto-dpif-xlate: Correctly decide whether truncating.

xlate_output_action() must tell some of the functions it calls whether the
packet is being truncated.  Until now, it has inferred that based on
whether its max_len argument is nonzero.

Unfortunately, max_len conflates two different purposes.  Historically it
was used only to limit the number of bytes of packets sent to an OpenFlow
controller in packet_in messages.  When packet truncation was introduced,
it was then also used to specify the truncation length.  This meant that,
for example, when xlate_output_reg_action() called into
xlate_output_action() passing along for max_len an OpenFlow controller byte
limit (which ovs-ofctl by default sets to 65535), xlate_output_action()
interpreted that as a truncation request and told the functions it called
that the packet was being truncated, which in the worst case led to
assertion failures.

This commit disentangles these two meaning of max_len, separating them into
two separate parameters, and updates the callers.

Reported-by: Kevin Lin <kevin at kelda.io>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2017-December/045841.html
Tested-by: Kevin Lin <kevin at kelda.io>
Signed-off-by: Ben Pfaff <blp at ovn.org>