The odp_flow_format() function applies a wildcard mask when a
mask for a given key was not present. However, in the context of
installing flows in the datapath, the absence of a mask actually
indicates that the key should be ignored, meaning it should not
be masked at all.
To address this inconsistency, odp_flow_format() now includes an
option to skip formatting keys that are missing a mask.
This was found during a debug session of the ‘datapath - ping between two
ports on cvlan’ test case. The log message was showing the following:
put[create] ufid:XX recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(3),
skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),
eth(src=12:f6:8b:52:f9:75,dst=6e:48:c8:77:d3:8c),eth_type(0x88a8),
vlan(vid=4094,pcp=0/0x0),encap(eth_type(0x8100),
vlan(vid=100/0x0,pcp=0/0x0),encap(eth_type(0x0800),
ipv4(src=10.2.2.2,dst=10.2.2.1,proto=1,tos=0,ttl=64,frag=no),
icmp(type=0,code=0))), actions:2
Where it should have shown the below:
put[create] ufid:XX recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(3),
skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),
eth(src=12:f6:8b:52:f9:75,dst=6e:48:c8:77:d3:8c),eth_type(0x88a8),
vlan(vid=4094,pcp=0/0x0),encap(eth_type(0x8100)), actions:2
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
The 'type' verification is incorrect, leading to a dead code warning.
The value OVS_NSH_KEY_ATTR_MAX represents the maximum value, not the
maximum plus one. This fix ensures that the OVS_NSH_KEY_ATTR_MD2 case
is reachable by changing the condition from 'greater than or equal'
to 'greater than'."
Fixes: 81fdabb94dd7 ("nsh: fix nested mask for OVS_KEY_ATTR_NSH")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Add support for parsing and formatting the new action.
Also, flag OVS_ACTION_ATTR_SAMPLE as requiring datapath assistance if it
contains a nested OVS_ACTION_ATTR_PSAMPLE. The reason is that the
sampling rate from the parent "sample" is made available to the nested
"psample" by the kernel.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Segments list in SRv6 header is 16-bit aligned as most of other fields
in packet headers. A little counter-intuitively, compilers are allowed
to make alignment assumptions based on the pointer type passed to
memcpy(), so they can use copy instructions that require 32-bit alignment
in case of struct in6_addr pointer. Reported by UBsan in Clang 18:
lib/netdev-native-tnl.c:985:16: runtime error: store to misaligned
address 0x7fd9e97351ce for type 'struct in6_addr *', which
requires 4 byte alignment
0x7fd9e97351ce: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
0 0xc1de38 in netdev_srv6_build_header lib/netdev-native-tnl.c:985:9
1 0x6e794b in tnl_port_build_header ofproto/tunnel.c:751:11
2 0x6c9c0a in native_tunnel_output ofproto/ofproto-dpif-xlate.c:3887:11
3 0x6c9c0a in compose_output_action__ ofproto/ofproto-dpif-xlate.c:4502:13
4 0x6b6646 in compose_output_action ofproto/ofproto-dpif-xlate.c:4564:5
5 0x6b6646 in xlate_output_action ofproto/ofproto-dpif-xlate.c:5517:13
6 0x68cfee in do_xlate_actions ofproto/ofproto-dpif-xlate.c:7288:13
7 0x67fed0 in xlate_actions ofproto/ofproto-dpif-xlate.c:8314:13
8 0x6468bd in ofproto_trace__ ofproto/ofproto-dpif-trace.c:782:30
9 0x64484a in ofproto_trace ofproto/ofproto-dpif-trace.c:851:5
10 0x647469 in ofproto_unixctl_trace ofproto/ofproto-dpif-trace.c:490:9
11 0xc33771 in process_command lib/unixctl.c:310:13
12 0xc33771 in run_connection lib/unixctl.c:344:17
13 0xc33771 in unixctl_server_run lib/unixctl.c:395:21
14 0x53e6ef in main vswitchd/ovs-vswitchd.c:131:9
15 0x7f61c7 in __libc_start_call_main (/lib64/libc.so.6+0x2a1c7)
16 0x7f628a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a28a)
17 0x42ca24 in _start (vswitchd/ovs-vswitchd+0x42ca24)
SUMMARY: UndefinedBehaviorSanitizer:
undefined-behavior lib/netdev-native-tnl.c:985:16
Having misaligned pointers is also generally not allowed in C, let
alone accessing memory through them.
Fix that by using an appropriate ovs_16aligned_in6_addr pointer instead.
Fixes: 7381fd440a88 ("odp: Add SRv6 tunnel actions.")
Fixes: 03fc1ad78521 ("userspace: Add SRv6 tunnel support.")
Reviewed-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This is prep for adding a different OVS_ACTION_ATTR_ enum value. This
action, OVS_ACTION_ATTR_DEC_TTL, is not actually implemented. However,
to make -Werror happy we must add a case to all existing switches.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The OpenFlow spec doesn't require that a user specify icmp_code when
specifying a type. However, the conversion for a DP flow asks that the
user explicitly specified an icmp_code field to match and forces this via
a mask check. This means that valid matches for icmp_type=136,... (for
example) won't properly generate a full flow and there will be a much
broader match installed in the kernel datapath.
This can be worked around by explicitly including icmp_code, but for users
that want to write flows which are installed in the kernel, it is not
possible to omit icmp_code in the openflow message and still have a
neighbor discovery match field included.
An alternative way to fix up the flow and mask would be to modify the
output of the translation in the xlate_wc_finish() to set the mask when
detecting a neighbor discovery related packet. This would require
additional matching logic in the xlate_wc_finish() path to validate the
ICMP type/code details, and set the masks correctly.
The approach taken here is to relax the requirements from the ODP side.
This follows the OpenFlow specification and only require that the user
include an 'icmp_type=' match, rather than both
'icmp_type=..,icmp_code=0' when matching on neighbor discovery.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add TC offload support for vxlan encap with gbp option.
Reviewed-by: Gavi Teitz <gavi@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Gavin Li <gavinl@nvidia.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Extract vxlan gbp option encoding to odp_encode_gbp_raw to be used in
following commits.
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Gavin Li <gavinl@nvidia.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Extract vxlan gbp option decoding to odp_decode_gbp_raw to be used in
following commits.
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Gavin Li <gavinl@nvidia.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
This patch adds ODP actions for SRv6 and its tests.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Make the order of the Netlink attributes for odp_flow_key_from_flow__()
the same as the kernel will return them.
This will make sure the attributes displayed in the dpctl/dump-flows
output appear in the same order for all datapath.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Tested-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
check_attr_len() currently reports all unknown keys as keys with bad
length. For example, IPv6 extension headers are printed out like this
in flow dumps:
eth_type(0x86dd),ipv6(...)
(bad key length 2, expected -1)(00 00/(bad mask length 2, expected -1)(00 00),
icmpv6(type=0/0,code=0/0)
However, since the key is unknown, the length check on it makes no
sense and should be ignored. This will allow the unknown key to be
caught later by the format_unknown_key() function and printed in a
more user-friendly way:
eth_type(0x86dd),ipv6(...),key32(00 00/00 00),icmpv6(type=0/0,code=0/0)
'32' here is the actual index of the key attribute, so we know
that it is unknown attribute #32 with the value/mask pair printed
out inside the parenthesis.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If OVS_CT_ATTR_TIMEOUT is included, the resulting output is
the following:
actions:ct(commit,timeout=1nat(src=10.1.1.240))
Fix it by trivially adding a trailing ',' to timeout as well.
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When processing netlink messages, we should ignore unknown OVS_KEY_ATTR
as we can assume if newer attributes are present, they are backward
compatible.
This patch also updates the existing comments to better explain what
happens in the error cases. At this place in the code, we can not
ignore the TOO_LITTLE/MUCH errors as some instances could have
canceled processing leaving the returning match data incomplete.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2089331
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Michael Santana <msantana@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
SUMMARY: UndefinedBehaviorSanitizer:
lib/odp-util.c:3436:32: runtime error:
load of misaligned address 0x624000489424 for type 'const ovs_be64'
(aka 'const unsigned long'), which requires 8 byte alignment 0x624000489424:
note: pointer points here
0c 00 00 00 ff ff ff ff ff ff ff ff 08 00 01 00 ...
^
0 0x9b13a2 in format_be64 lib/odp-util.c:3436:32
1 0x9b13a2 in format_odp_tun_attr lib/odp-util.c:3942:13
2 0x9b13a2 in format_odp_key_attr__ lib/odp-util.c:4221:9
3 0x9ae7a2 in odp_flow_format lib/odp-util.c:4606:17
4 0xee5037 in format_dpif_flow lib/dpctl.c:862:5
5 0xed69ed in dpctl_dump_flows lib/dpctl.c:1142:13
6 0xed32b3 in dpctl_unixctl_handler lib/dpctl.c:3035:17
7 0xc7c80b in process_command lib/unixctl.c:310:13
8 0xc7c80b in run_connection lib/unixctl.c:344:17
9 0xc7c80b in unixctl_server_run lib/unixctl.c:395:21
10 0x59a9a4 in main vswitchd/ovs-vswitchd.c:130:9
11 0x7fee2803acf2 in __libc_start_main (/lib64/libc.so.6+0x3acf2)
12 0x47e60d in _start (vswitchd/ovs-vswitchd+0x47e60d)
Tunnel id mask in the flow key is only 4 bytes aligned, so has to be
accessed with appropriate unaligned read function.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The parse_key_and_mask_to_match() is a function to translate
a netlink formatted key/mask to match structure. And should
not consider any configuration setting when translating.
In addition we also enforce the encap_eth_type[0] mask as
it's required for the VLAN match.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This reverts commit c645550bb249 ("odp-util: Always report
ODP_FIT_TOO_LITTLE for IGMP.")
Always forcing a slow path action can result in some over-broad
flows which swallow all traffic and force them to userspace, as reported
in the thread at
https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/387706.html
and at
https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/387689.html
Revert the ODP_FIT_TOO_LITTLE return for IGMP specifically.
Additionally, remove the userspace wc mask to prevent revalidator from
cycling flows.
Fixes: c645550bb249 ("odp-util: Always report ODP_FIT_TOO_LITTLE for IGMP.")
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Upstream commit:
commit 1926407a4ab0e59d5a27bed7b82029b356d80fa0
Author: Ilya Maximets <i.maximets@ovn.org>
Date: Wed Mar 9 23:20:33 2022 +0100
net: openvswitch: fix uAPI incompatibility with existing user space
Few years ago OVS user space made a strange choice in the commit [1]
to define types only valid for the user space inside the copy of a
kernel uAPI header. '#ifndef __KERNEL__' and another attribute was
added later.
This leads to the inevitable clash between user space and kernel types
when the kernel uAPI is extended. The issue was unveiled with the
addition of a new type for IPv6 extension header in kernel uAPI.
When kernel provides the OVS_KEY_ATTR_IPV6_EXTHDRS attribute to the
older user space application, application tries to parse it as
OVS_KEY_ATTR_PACKET_TYPE and discards the whole netlink message as
malformed. Since OVS_KEY_ATTR_IPV6_EXTHDRS is supplied along with
every IPv6 packet that goes to the user space, IPv6 support is fully
broken.
Fixing that by bringing these user space attributes to the kernel
uAPI to avoid the clash. Strictly speaking this is not the problem
of the kernel uAPI, but changing it is the only way to avoid breakage
of the older user space applications at this point.
These 2 types are explicitly rejected now since they should not be
passed to the kernel. Additionally, OVS_KEY_ATTR_TUNNEL_INFO moved
out from the '#ifdef __KERNEL__' as there is no good reason to hide
it from the userspace. And it's also explicitly rejected now, because
it's for in-kernel use only.
Comments with warnings were added to avoid the problem coming back.
(1 << type) converted to (1ULL << type) to avoid integer overflow on
OVS_KEY_ATTR_IPV6_EXTHDRS, since it equals 32 now.
[1] beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")
Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support")
Link: https://lore.kernel.org/netdev/3adf00c7-fe65-3ef4-b6d7-6d8a0cad8a5f@nvidia.com
Link: beb75a40fd
Reported-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Link: https://lore.kernel.org/r/20220309222033.3018976-1-i.maximets@ovn.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Not adding OVS_KEY_ATTR_IPV6_EXTHDRS in this commit as this is not
necessary. Will be added along with the actual userspace
implementation.
This change should help avoiding incompatibility issues in the future.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When the same flow is programmed in the kernel and tc, they
look different due to the way they are translated. They take
the userspace approach by always including the packet type
attribute. To make the outputs the same, show the ethernet
header when the packet type is wildcarded, and not printed.
So without the fix the kernel would show (ovs-appctl dpctl/dump-flows):
in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), ..., actions:output
Where as TC would show:
in_port(3),eth_type(0x0800),ipv4(frag=no), ..., actions:output
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The encap & decap actions are extended to support MPLS packet type.
Encap & decap actions adds and removes MPLS header at start of the
packet.
The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS
header between ethernet header and the IP header. Though this behaviour
is fine for L3 VPN where an IP packet is encapsulated inside a MPLS
tunnel, it does not suffice the L2 VPN requirements. In L2 VPN the
ethernet packets must be encapsulated inside MPLS tunnel.
In this change the encap & decap actions are extended to support MPLS
packet type. The encap & decap adds and removes MPLS header at the
start of packet as depicted below.
Encapsulation:
Actions - encap(mpls),encap(ethernet)
Incoming packet -> | ETH | IP | Payload |
1 Actions - encap(mpls) [Datapath action - ADD_MPLS:0x8847]
Outgoing packet -> | MPLS | ETH | Payload|
2 Actions - encap(ethernet) [ Datapath action - push_eth ]
Outgoing packet -> | ETH | MPLS | ETH | Payload|
Decapsulation:
Incoming packet -> | ETH | MPLS | ETH | IP | Payload |
Actions - decap(),decap(packet_type(ns=0,type=0))
1 Actions - decap() [Datapath action - pop_eth)
Outgoing packet -> | MPLS | ETH | IP | Payload|
2 Actions - decap(packet_type(ns=0,type=0)) [Datapath action - POP_MPLS:0x6558]
Outgoing packet -> | ETH | IP | Payload|
Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The fuzzing target times out if the action list is too big. And we
don't really need to fully parse all the actions just to say that they
are too big in the end. So, check early and exit.
This is a pure performance optimization, so not adding a unit test.
All other code paths during the parsing are using E2BIG and not EFBIG
for similar conditions, so using it here too.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39670
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch fixes (dereference after null check) coverity issue.
For this reason, we should add null check of 'mask' before calling
nl_attr_find__() because the 'mask' maybe null.
Addresses-Coverity: ("Dereference after null check")
Fixes: e6cc0babc25d ("ovs-dpctl: Add mega flow support")
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Vasu Dasari <vdasari@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch fixes (dereference after null check) coverity issue.
We should add null check of 'nsh_mask' to avoid passing NULL pointer
to memcpy() because the 'nsh_mask' maybe null.
Addresses-Coverity: ("Dereference after null check")
Fixes: 81fdabb94dd7 ("nsh: fix nested mask for OVS_KEY_ATTR_NSH")
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
We don't need to continue parsing if already oversized. This is not
very important, but fuzzer times out while parsing very long flow.
The check could be written as a single 'if' statement, but I found
my variant much more readable.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35519
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
When a decap action is applied on NSH header encapsulating a
ethernet packet a redundant set mac address action is programmed
to the datapath.
Fixes: f839892a206a ("OF support and translation of generic encap and decap")
Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
Acked-by: Jan Scheurich <jan.scheurich@ericsson.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
We don't need to continue parsing if already oversized. This is not
very important, but fuzzer times out while parsing very long list of
actions.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29190
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
'struct erspan_metadata' contains union with fields of different
sizes, hence not all the memory initiliazed. This memory goes
to syscalls and also used to compare ukeys with memcmp which may
cause unexpected behavior.
Thread 15 revalidator13:
Conditional jump or move depends on uninitialised value(s)
at 0x4C377B6: bcmp (vg_replace_strmem.c:1111)
by 0x43F844: ofpbuf_equal (ofpbuf.h:273)
by 0x43F844: revalidate_ukey__ (ofproto-dpif-upcall.c:2227)
by 0x43F9C9: revalidate_ukey (ofproto-dpif-upcall.c:2294)
by 0x4425C2: revalidate.isra.33 (ofproto-dpif-upcall.c:2734)
by 0x4434B8: udpif_revalidator (ofproto-dpif-upcall.c:943)
by 0x4FDE2C: ovsthread_wrapper (ovs-thread.c:383)
by 0x5E19159: start_thread (in /usr/lib64/libpthread-2.28.so)
by 0x69ECF72: clone (in /usr/lib64/libc-2.28.so)
Uninitialised value was created by a stack allocation
at 0x4B1CE0: tun_key_to_attr (odp-util.c:3129)
Fixes: 98514eea21f4 ("erspan: add kernel datapath support")
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
OVS should not exit if it cannot format NSH actions for the user.
It should just report the error like the other formatting functions do.
Credit to OSS-Fuzz.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21509
Fixes: 1fc11c5948cf ("Generic encap and decap support for NSH")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Mark Gray <mark.d.gray@redhat.com>
Too big userdata could overflow netlink message leading to out-of-bound
memory accesses or assertion while formatting nested actions.
Fix that by checking the size and returning correct error code.
Credit to OSS-Fuzz.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27640
Fixes: e995e3df57ea ("Allow OVS_USERSPACE_ATTR_USERDATA to be variable length.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Length of nested attributes must be checked before storing to the
header. If current length exceeds the maximum value parsing should
fail, otherwise the length value will be truncated leading to
corrupted netlink message and out-of-bound memory accesses:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310002cc838
at pc 0x000000575470 bp 0x7ffc6c322d60 sp 0x7ffc6c322d58
READ of size 1 at 0x6310002cc838 thread T0
SCARINESS: 12 (1-byte-read-heap-buffer-overflow)
#0 0x57546f in format_generic_odp_key lib/odp-util.c:2738:39
#1 0x559e70 in check_attr_len lib/odp-util.c:3572:13
#2 0x56581a in format_odp_key_attr lib/odp-util.c:4392:9
#3 0x5563b9 in format_odp_action lib/odp-util.c:1192:9
#4 0x555d75 in format_odp_actions lib/odp-util.c:1279:13
...
Fix that by checking the length of nested netlink attributes before
updating 'nla_len' inside the header. Additionally introduced
assertion inside nl_msg_end_nested() to catch this kind of issues
before actual overflow happened.
Credit to OSS-Fuzz.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20003
Fixes: 65da723b40a5 ("odp-util: Format tunnel attributes directly from netlink.")
Acked-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently flows are printed like this:
'tunnel(gtpu(flags=0x7f,msgtype=0)flags(0))'
With this change:
'tunnel(gtpu(flags=0x7f,msgtype=0),flags(0))'
Fixes: 3c6d05a02e0f ("userspace: Add GTP-U support.")
Acked-by: Yi Yang <yangyi01@inspur.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If datapath flow doesn't have one of the fields of gtpu metadata, e.g.
'tunnel(gtpu())', uninitialized stack memory will be used instead.
==3485429==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x853a1b in format_u8x lib/odp-util.c:3474:13
#1 0x86ee9c in format_odp_tun_gtpu_opt lib/odp-util.c:3713:5
#2 0x86a099 in format_odp_tun_attr lib/odp-util.c:3973:13
#3 0x83afe6 in format_odp_key_attr__ lib/odp-util.c:4179:9
#4 0x838afb in odp_flow_format lib/odp-util.c:4563:17
#5 0x738422 in log_flow_message lib/dpif.c:1750:5
#6 0x738e2f in log_flow_put_message lib/dpif.c:1784:9
#7 0x7371a4 in dpif_operate lib/dpif.c:1377:21
#8 0x7363ef in dpif_flow_put lib/dpif.c:1035:5
#9 0xc7aab7 in dpctl_put_flow lib/dpctl.c:1171:13
#10 0xc65a4f in dpctl_unixctl_handler lib/dpctl.c:2701:17
#11 0xaaad04 in process_command lib/unixctl.c:308:13
#12 0xaa87f7 in run_connection lib/unixctl.c:342:17
#13 0xaa842e in unixctl_server_run lib/unixctl.c:393:21
#14 0x51c09c in main vswitchd/ovs-vswitchd.c:128:9
#15 0x7f88344391a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#16 0x46b92d in _start (vswitchd/ovs-vswitchd+0x46b92d)
Uninitialized value was stored to memory at
#0 0x87da17 in scan_gtpu_metadata lib/odp-util.c:5221:27
#1 0x874588 in parse_odp_key_mask_attr__ lib/odp-util.c:5862:9
#2 0x83ee14 in parse_odp_key_mask_attr lib/odp-util.c:5808:18
#3 0x83e8b5 in odp_flow_from_string lib/odp-util.c:6065:18
#4 0xc7a4f3 in dpctl_put_flow lib/dpctl.c:1145:13
#5 0xc65a4f in dpctl_unixctl_handler lib/dpctl.c:2701:17
#6 0xaaad04 in process_command lib/unixctl.c:308:13
#7 0xaa87f7 in run_connection lib/unixctl.c:342:17
#8 0xaa842e in unixctl_server_run lib/unixctl.c:393:21
#9 0x51c09c in main vswitchd/ovs-vswitchd.c:128:9
#10 0x7f88344391a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Uninitialized value was created by an allocation of 'msgtype_ma' in the
stack frame of function 'scan_gtpu_metadata'
#0 0x87d440 in scan_gtpu_metadata lib/odp-util.c:5187
Fix that by initializing fields to all zeroes by default.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21426
Fixes: 3c6d05a02e0f ("userspace: Add GTP-U support.")
Acked-by: Yi Yang <yangyi01@inspur.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Silimar to the patch 67eb8110171f ("odp-util: Fix passing
uninitialized bytes in OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV*.")
when change from flow into the netlink format, the tail
padding of nd_extension should be cleared.
this fixes the following warning logs:
|ofproto_dpif_upcall(pmd-...)|WARN|Conflicting ukey for flows:
ufid:763c7d3b-4d0c-4bff-aafc-fdfb6089c2ba
<...>,eth(...),eth_type(0x86dd),ipv6(...),icmpv6(type=135,code=0),\
nd(target=fdbd:dc02:ff:1:1::1,sll=fa:16:3e:75:b3:a9,tll=00:00:00:00:00:00),\
nd_ext(nd_reserved=0x0,nd_options_type=1)
ufid:763c7d3b-4d0c-4bff-aafc-fdfb6089c2ba
<...>,eth(...),eth_type(0x86dd),ipv6(...),icmpv6(type=135,code=0),\
nd(target=fdbd:dc02:ff:1:1::1,sll=fa:16:3e:75:b3:a9,tll=00:00:00:00:00:00),\
nd_ext(nd_reserved=0x0,nd_options_type=1)
|ofproto_dpif_upcall(pmd-...)|WARN|upcall_cb failure: ukey installation fails
Fixes: 9b2b84973db7 ("Support for match & set ICMPv6 reserved and options type fields")
Signed-off-by: Peng He <hepeng.0320@bytedance.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While committing set() actions, commit() could wildcard all the fields
that are same in match key and in the set action. This leads to
situation where mask after commit could actually contain less bits
than it was before. And if set action was partially committed, all
the fields that were the same will be cleared out from the matching key
resulting in the incorrect (too wide) flow.
For example, for the flow that matches on both src and dst mac
addresses, if the dst mac is the same and only src should be changed
by the set() action, destination address will be wildcarded in the
match key and will never be matched, i.e. flows with any destination
mac will match, which is not correct.
Setting OF rule:
in_port=1,dl_src=50:54:00:00:00:09 actions=mod_dl_dst(50:54:00:00:00:0a),output(2)
Sending following packets on port 1:
1. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800)
2. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),eth_type(0x0800)
3. eth(src=50:54:00:00:00:0b,dst=50:54:00:00:00:0c),eth_type(0x0800)
Resulted datapath flows:
eth(dst=50:54:00:00:00:0c),<...>, actions:set(eth(dst=50:54:00:00:00:0a)),2
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
The first flow doesn't have any match on source MAC address and the
third packet successfully matched on it while it must be dropped.
Fix that by updating the match mask with only the new bits set by
commit(), but keeping those that were cleared (OR operation).
With fix applied, resulted correct flows are:
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),<...>,
actions:set(eth(dst=50:54:00:00:00:0a)),2
eth(src=50:54:00:00:00:0b),<...>, actions:drop
The code before commit dbf4a92800d0 was not able to reduce the mask,
it was only possible to expand it to exact match, so it was OK to
update original matching mask with the new value in all cases.
Fixes: dbf4a92800d0 ("odp-util: Do not rewrite fields with the same values as matched")
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1854376
Acked-by: Eli Britstein <elibr@mellanox.com>
Tested-by: Adrián Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Problem:
In OVS, flows with output over a bond interface of type “balance-tcp”
gets translated by the ofproto layer into "HASH" and "RECIRC" datapath
actions. After recirculation, the packet is forwarded to the bond
member port based on 8-bits of the datapath hash value computed through
dp_hash. This causes performance degradation in the following ways:
1. The recirculation of the packet implies another lookup of the
packet’s flow key in the exact match cache (EMC) and potentially
Megaflow classifier (DPCLS). This is the biggest cost factor.
2. The recirculated packets have a new “RSS” hash and compete with the
original packets for the scarce number of EMC slots. This implies more
EMC misses and potentially EMC thrashing causing costly DPCLS lookups.
3. The 256 extra megaflow entries per bond for dp_hash bond selection
put additional load on the revalidation threads.
Owing to this performance degradation, deployments stick to “balance-slb”
bond mode even though it does not do active-active load balancing for
VXLAN- and GRE-tunnelled traffic because all tunnel packet have the
same source MAC address.
Proposed optimization:
This proposal introduces a new load-balancing output action instead of
recirculation.
Maintain one table per-bond (could just be an array of uint16's) and
program it the same way internal flows are created today for each
possible hash value (256 entries) from ofproto layer. Use this table to
load-balance flows as part of output action processing.
Currently xlate_normal() -> output_normal() ->
bond_update_post_recirc_rules() -> bond_may_recirc() and
compose_output_action__() generate 'dp_hash(hash_l4(0))' and
'recirc(<RecircID>)' actions. In this case the RecircID identifies the
bond. For the recirculated packets the ofproto layer installs megaflow
entries that match on RecircID and masked dp_hash and send them to the
corresponding output port.
Instead, we will now generate action as
'lb_output(<bond id>)'
This combines hash computation (only if needed, else re-use RSS hash)
and inline load-balancing over the bond. This action is used *only* for
balance-tcp bonds in userspace datapath (the OVS kernel datapath
remains unchanged).
Example:
Current scheme:
With 8 UDP flows (with random UDP src port):
flow-dump from pmd on cpu core: 2
recirc_id(0),in_port(7),<...> actions:hash(hash_l4(0)),recirc(0x1)
recirc_id(0x1),dp_hash(0xf8e02b7e/0xff),<...> actions:2
recirc_id(0x1),dp_hash(0xb236c260/0xff),<...> actions:1
recirc_id(0x1),dp_hash(0x7d89eb18/0xff),<...> actions:1
recirc_id(0x1),dp_hash(0xa78d75df/0xff),<...> actions:2
recirc_id(0x1),dp_hash(0xb58d846f/0xff),<...> actions:2
recirc_id(0x1),dp_hash(0x24534406/0xff),<...> actions:1
recirc_id(0x1),dp_hash(0x3cf32550/0xff),<...> actions:1
New scheme:
We can do with a single flow entry (for any number of new flows):
in_port(7),<...> actions:lb_output(1)
A new CLI has been added to dump datapath bond cache as given below.
# ovs-appctl dpif-netdev/bond-show [dp]
Bond cache:
bond-id 1 :
bucket 0 - slave 2
bucket 1 - slave 1
bucket 2 - slave 2
bucket 3 - slave 1
Co-authored-by: Manohar Krishnappa Chidambaraswamy <manukc@gmail.com>
Signed-off-by: Manohar Krishnappa Chidambaraswamy <manukc@gmail.com>
Signed-off-by: Vishal Deep Ajmera <vishal.deep.ajmera@ericsson.com>
Tested-by: Matteo Croce <mcroce@redhat.com>
Tested-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When dp_hash is executed with slowpath actions, it results in endless
recirc loop in kernel datapath, and finally drops the packet, with
kernel logs:
openvswitch: ovs-system: deferred action limit reached, drop recirc action
The root cause is that the dp_hash value calculated by slowpath is not
passed to datapath when executing the recirc action, thus when the recirced
packet miss upcall comes to userspace again, it generates the dp_hash
and recirc action again, with same recirc_id, which in turn generates
a megaflow with recirc action with the recird_id same as the recirc_id in
its match condition, which causes a loop in datapath.
For example, this can be reproduced with below setup of OVN environment:
LS1 LS2
| |
|------R1------|
VIF--LS0---R0-----| |------R3
|------R2------|
Assume there is a route from the VIF to R3: R0 -> R1 -> R3, and there are two
routes (ECMP) from R3 to the VIF:
R3 -> R1 -> R0
R3 -> R2 -> R0
Now if we ping from the VIF to R3, the OVS flow execution on the HV of the VIF
will hit the R3's datapath which has flows that responds to the ICMP packet
by setting ICMP fields, which requires slowpath actions, and in later flow
tables it will hit the "group" action that selects between the ECMP routes.
By default OVN uses "dp_hash" method for the "group" action.
For the first miss upcall packet, dp_hash value is empty, so the group action
will be translated to "dp_hash" and "recirc".
During action execution, because of the previous actions that sets ICMP fields,
the whole execution requires slowpath, so it tries to execute all actions in
userspace in odp_execute_actions(), including dp_hash action, except the
recirc action, which can only be executed in datapath. So the dp_hash value
is calculated in userspace, and then the packet is injected to datapath for
recirc action execution.
However, the dp_hash calculated by the userspace is not passed to datapath.
Because of this, the packet recirc in datapath doesn't have dp_hash value,
and the miss upcall for the recirced packet hits the same flow tables and
triggers same "dp_hash" and "recirc" action again, with exactly same recirc_id!
This time, the new upcall doesn't require any slowpath execution, so both
the dp_hash and recirc actions are executed in datapath, after creating a
datapath megaflow like:
recirc_id(XYZ),..., actions:hash(l4(0)),recirc(XYZ)
with match recirc_id equals the recirc id in the action, thus creating a loop.
This patch fixes the problem by passing the calculated dp_hash value to
datapath in odp_key_from_dp_packet().
Fixes: 572f732ab078 ("dpif-netdev: user space datapath recirculation")
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch allows to install arp rules to tc dp.
In the future, arp will be offloaded to hardware to
be processed. So OvS enable this now.
$ ovs-appctl dpctl/add-flow 'recirc_id(0),in_port(3),eth(),\
eth_type(0x0806),arp(op=2,tha=00:50:56:e1:4b:ab,tip=10.255.1.116)' 2
$ ovs-appctl dpctl/dump-flows
... arp(tip=10.255.1.116,op=2,tha=00:50:56:e1:4b:ab) ...
$ tc filter show dev <ethx> ingress
...
eth_type arp
arp_tip 10.255.1.116
arp_op reply
arp_tha 00:50:56:e1:4b:ab
not_in_hw
action order 1: mirred (Egress Redirect to device <ethy>) stolen
...
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
To support more use case, for example, DDOS, which
packets should be dropped in hardware, this patch
allows users to match only the tunnel source IPs with
masked value.
$ ovs-appctl dpctl/add-flow "tunnel(src=2.2.2.0/255.255.255.0,tp_dst=4789,ttl=64),\
recirc_id(2),in_port(3),eth(),eth_type(0x0800),ipv4()" ""
$ ovs-appctl dpctl/dump-flows
tunnel(src=2.2.2.0/255.255.255.0,ttl=64,tp_dst=4789) ... actions:drop
$ tc filter show dev vxlan_sys_4789 ingress
...
eth_type ipv4
enc_src_ip 2.2.2.0/24
enc_dst_port 4789
enc_ttl 64
in_hw in_hw_count 2
action order 1: gact action drop
...
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
GTP, GPRS Tunneling Protocol, is a group of IP-based communications
protocols used to carry general packet radio service (GPRS) within
GSM, UMTS and LTE networks. GTP protocol has two parts: Signalling
(GTP-Control, GTP-C) and User data (GTP-User, GTP-U). GTP-C is used
for setting up GTP-U protocol, which is an IP-in-UDP tunneling
protocol. Usually GTP is used in connecting between base station for
radio, Serving Gateway (S-GW), and PDN Gateway (P-GW).
This patch implements GTP-U protocol for userspace datapath,
supporting only required header fields and G-PDU message type.
See spec in:
https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-00
Tested-at: https://travis-ci.org/github/williamtu/ovs-travis/builds/666518784
Signed-off-by: Feng Yang <yangfengee04@gmail.com>
Co-authored-by: Feng Yang <yangfengee04@gmail.com>
Signed-off-by: Yi Yang <yangyi01@inspur.com>
Co-authored-by: Yi Yang <yangyi01@inspur.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Acked-by: Ben Pfaff <blp@ovn.org>
Both ovs_key_ct_tuple_ipv* structures contains padding at the end
that mast be cleared before passing attributes to kernel:
Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
at 0x566A607: sendmsg (sendmsg.c:28)
by 0xFC95CE: nl_sock_transact_multiple__ (netlink-socket.c:858)
by 0xFC8580: nl_sock_transact_multiple (netlink-socket.c:1079)
by 0xFC83FF: nl_transact_multiple (netlink-socket.c:1839)
by 0xFA8648: dpif_netlink_operate__ (dpif-netlink.c:1926)
by 0xFA789F: dpif_netlink_operate_chunks (dpif-netlink.c:2219)
by 0xFA25CB: dpif_netlink_operate (dpif-netlink.c:2278)
by 0xE5BB4C: dpif_operate (dpif.c:1377)
by 0xE5B7F6: dpif_flow_put (dpif.c:1048)
by 0xE5B49A: dpif_probe_feature (dpif.c:965)
by 0xDD6BF5: check_ct_orig_tuple (ofproto-dpif.c:1557)
by 0xDD41EC: check_support (ofproto-dpif.c:1590)
by 0xDD3BF3: open_dpif_backer (ofproto-dpif.c:818)
by 0xDC8467: construct (ofproto-dpif.c:1605)
by 0xDAD6BB: ofproto_create (ofproto.c:549)
by 0xD96A19: bridge_reconfigure (bridge.c:877)
by 0xD9625D: bridge_run (bridge.c:3324)
by 0xDA5829: main (ovs-vswitchd.c:127)
Address 0x1ffefe36a5 is on thread 1's stack
in frame #4, created by dpif_netlink_operate__ (dpif-netlink.c:1839)
Uninitialised value was created by a stack allocation
at 0xEB87D0: odp_flow_key_from_flow__ (odp-util.c:5996)
Fixes: daf4d3c18da4 ("odp: Support conntrack orig tuple key.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Current implementation of dpif_flow_hash() doesn't depend on datapath
interface and only complicates the callers by forcing them to figure
out what is their current 'dpif'. If we'll need different hashing
for different 'dpif's we'll implement an API for dpif-providers
and each dpif implementation will be able to use their local function
directly without calling it via dpif API.
This change will allow us to not store 'dpif' pointer in the userspace
datapath implementation which is broken and will be removed in next
commits.
This patch moves dpif_flow_hash() to odp-util module and replaces
unused odp_flow_key_hash() by it, along with removing of unused 'dpif'
argument.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Currently OVS maintains explicit packet drop/error counters only on port
level. Packets that are dropped as part of normal OpenFlow processing
are counted in flow stats of “drop” flows or as table misses in table
stats. These can only be interpreted by controllers that know the
semantics of the configured OpenFlow pipeline. Without that knowledge,
it is impossible for an OVS user to obtain e.g. the total number of
packets dropped due to OpenFlow rules.
Furthermore, there are numerous other reasons for which packets can be
dropped by OVS slow path that are not related to the OpenFlow pipeline.
The generated datapath flow entries include a drop action to avoid
further expensive upcalls to the slow path, but subsequent packets
dropped by the datapath are not accounted anywhere.
Finally, the datapath itself drops packets in certain error situations.
Also, these drops are today not accounted for.This makes it difficult
for OVS users to monitor packet drop in an OVS instance and to alert a
management system in case of a unexpected increase of such drops.
Also OVS trouble-shooters face difficulties in analysing packet drops.
With this patch we implement following changes to address the issues
mentioned above.
1. Identify and account all the silent packet drop scenarios
2. Display these drops in ovs-appctl coverage/show
Co-authored-by: Rohith Basavaraja <rohith.basavaraja@gmail.com>
Co-authored-by: Keshav Gupta <keshugupta1@gmail.com>
Signed-off-by: Anju Thomas <anju.thomas@ericsson.com>
Signed-off-by: Rohith Basavaraja <rohith.basavaraja@gmail.com>
Signed-off-by: Keshav Gupta <keshugupta1@gmail.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com
Acked-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The IPv6 ND Extensions is only implemented in userspace datapath,
but nothing prevents that to be used with other datapaths.
This patch probes the datapath and only allows if the support
is available.
Fixes: 9b2b84973 ("Support for match & set ICMPv6 reserved and options type fields")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds support for specifying a timeout policy for a
connection in connection tracking system in kernel datapath.
The timeout policy will be attached to a connection when the
connection is committed to conntrack.
This patch introduces a new odp field OVS_CT_ATTR_TIMEOUT in the
ct action that specifies the timeout policy in the datapath.
In the following patch, during the upcall process, the vswitchd will use
the ct_zone to look up the corresponding timeout policy and fill
OVS_CT_ATTR_TIMEOUT if it is available.
The datapath code is from the following two net-next upstream commits.
Upstream commit:
commit 06bd2bdf19d2f3d22731625e1a47fa1dff5ac407
Author: Yi-Hung Wei <yihung.wei@gmail.com>
Date: Tue Mar 26 11:31:14 2019 -0700
openvswitch: Add timeout support to ct action
Add support for fine-grain timeout support to conntrack action.
The new OVS_CT_ATTR_TIMEOUT attribute of the conntrack action
specifies a timeout to be associated with this connection.
If no timeout is specified, it acts as is, that is the default
timeout for the connection will be automatically applied.
Example usage:
$ nfct timeout add timeout_1 inet tcp syn_sent 100 established 200
$ ovs-ofctl add-flow br0 in_port=1,ip,tcp,action=ct(commit,timeout=timeout_1)
CC: Pravin Shelar <pshelar@ovn.org>
CC: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 6d670497e01803b486aa72cc1a718401ab986896
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Apr 2 09:53:14 2019 +0300
openvswitch: use after free in __ovs_ct_free_action()
We free "ct_info->ct" and then use it on the next line when we pass it
to nf_ct_destroy_timeout(). This patch swaps the order to avoid the use
after free.
Fixes: 06bd2bdf19d2 ("openvswitch: Add timeout support to ct action")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
When parse tnl_push, if IPv4 is used,
we forget to fill the ipv4 version and ip header length fields.
so there is a wrong ip header in the header of "struct ovs_action_push_tnl",
which will caused wrong packdet sent by dpcl.
test command:
ovs-appctl dpctl/add-flow "in_port(1),eth_type(0x0800),ipv4(dst=9.9.9.6)" \
"tnl_push(tnl_port(2),header(size=50,type=4,eth(dst=08:00:27:2e:87:0d,src=98:03:9b:c6:d1:7c,dl_type=0x0800), \
ipv4(src=10.97.240.147,dst=10.96.74.33,proto=17,tos=0,ttl=64,frag=0x4000), \
udp(src=0,dst=4789,csum=0x0),vxlan(flags=0x8000000,vni=0x270f)),out_port(3)),4"
Signed-off-by: Martin Zhang <martinbj2008@gmail.com>
Signed-off-by: Dujie <dujie@didiglobal.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
'odp_flow_key_to_flow__' is used to parse both keys and masks.
However, 'odp_nsh_key_from_attr' expects only 'key' as an argument
and fails to parse masks with ODP_FIT_ERROR which causes userspace
system tests failures:
# make check-system-userspace TESTSUITEFLAGS='-k nsh'
|odp_util(revalidator)|WARN|
OVS_NSH_KEY_ATTR_MD1 present but declared mdtype 0 is not 1 (NSH_M_TYPE1)
|odp_util(revalidator)|WARN|
the flow mask in error is:
<...> nsh(flags=0ttl=0,mdtype=0,np=255,spi=0x0,si=0),
for the following flow key:
<...> nsh_ttl=8,nsh_mdtype=1,nsh_np=3,nsh_spi=0x64,nsh_si=3,
nsh_c1=0x1020304,nsh_c2=0x5060708,nsh_c3=0x90a0b0c,nsh_c4=0xd0e0f10
<...>
Fix that by passing the additional argument 'is_mask' to make it be
like all other parsing functions.
Additionally fixed missing comma in the 'format_nsh_key'.
CC: Yi Yang <yi.y.yang@intel.com>
Fixes: f59cb331c481 ("nsh: rework NSH netlink keys and actions")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: William Tu <u9012063@gmail.com>
