- 30 Jun, 2022 1 commit
-
-
Luca Boccassi authored
-
- 15 Jun, 2022 1 commit
-
-
Ilya Maximets authored
Acked-by:
Aaron Conole <aconole@redhat.com> Signed-off-by:
Ilya Maximets <i.maximets@ovn.org>
-
- 07 Jun, 2022 3 commits
-
-
Frode Nordahl authoredIn some circumstances a flow may get its ct_state set without conscious intervention by the OVS user space code. Commit 355fef6f optimizes out unnecessary ct_clear actions based on an internal struct xlate_ctx->conntracked state flag. Before this commit the xlate_ctx->conntracked state flag would be initialized to 'false' and only set during thawing for recirculation. This patch checks the flow ct_state for the non-recirc case and sets the internal conntracked state appropriately. A system traffic test is also added to avoid regression. Fixes: 355fef6f ("ofproto-dpif-xlate: Avoid successive ct_clear datapath actions.") Signed-off-by:
Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: -
Aaron Conole authored
During flow processing, the flow wildcards are checked as a series of stages, and these stages are intended to carry dependencies in a single direction. But when the neighbor discovery processing, for example, was executed there is an incorrect dependency chain - we need fields from stage 4 to determine whether we need fields from stage 3. We can build a set of flow rules to demonstrate this: table=0,priority=100,ipv6,ipv6_src=1000::/10 actions=resubmit(,1) table=0,priority=0 actions=NORMAL table=1,priority=110,ipv6,ipv6_dst=1000::3 actions=resubmit(,2) table=1,priority=100,ipv6,ipv6_dst=1000::4 actions=resubmit(,2) table=1,priority=0 actions=NORMAL table=2,priority=120,icmp6,nw_ttl=255,icmp_type=135,icmp_code=0,nd_sll=10:de:ad:be:ef:10 actions=NORMAL table=2,priority=100,tcp actions=NORMAL table=2,priority=100,icmp6 actions=NORMAL table=2,priority=0 actions=NORMAL With this set of flows, any IPv6 packet that executes through this pipeline will have the corresponding nd_sll field flagged as required match for classification even if that field doesn't make sense in such a context (for example, TCP packets). When the corresponding flow is installed into the kernel datapath, this field is not reflected when the revalidator executes the dump stage (see net/openvswitch/flow_netlink.c for more details). During the sweep stage, revalidator will compare the dumped WC with a generated WC - these will mismatch because the generated WC will match on the Neighbor Discovery fields, while the datapath WC will not match on these fields. We will then invalidate the flow and as a side effect force an upcall. By redefining the boundary, we shift these fields to the l4 subtable, and cause masks to be generated matching just the requisite fields. The list of fields being shifted: struct in6_addr nd_target; struct eth_addr arp_sha; struct eth_addr arp_tha; ovs_be16 tcp_flags; ovs_be16 pad2; struct ovs_key_nsh nsh; A standout field would be tcp_flags moving from l3 subtable matches to the l4 subtable matches. This reverts a partial performance optimization in the case of stateless firewalling. The tcp_flags field might have been a good candidate to retain in the l3 segment, but it got overloaded with ICMPv6 ND matching, and therefore we can't preserve this kind of optimization. Two other approaches were considered - moving the nd_target field alone and collapsing the l3/l4 segments into a single subtable for matching. Moving any field individually introduces ABI mismatch, and doesn't completely address the problems with other neighbor discovery related fields (such as nd_sll/nd_tll). Collapsing the two subtables creates an issue with datapath flow explosion, since the l3 and l4 fields will be unwildcarded together (this can be seen with some of the existing classifier tests). A simple test is added to showcase the behavior. Fixes: 476f36e8 ("Classifier: Staged subtable matching.") Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2081773 Reported-by:Numan Siddique <nusiddiq@redhat.com> Suggested-by:
Eelco Chaudron <echaudro@redhat.com> Acked-by:
Cian Ferriter <cian.ferriter@intel.com> Tested-by:
Numan Siddique <numans@ovn.org> Signed-off-by:
-
Han Ding authored
Sometimes we need to dump packets on more than two interfaces in a bridge at the same time. Then when we stop dumping in order, ovs-tcpdump print traceback and fail to delete mirror interface for some interface. For example: br-int has two interface tap1 and br-int. We use ovs-tcpdump dump tap1 first and dump br-int next. Then stopping tap1 ovs-tcpdump first, and stopping br-int second. When we stop ovs-tcpdump for br-int, the screen show the error like this: __main__.OVSDBException: Unable to delete Mirror m_br-int Signed-off-by:
Han Ding <handing@chinatelecom.cn> Acked-by:
Mike Pattrick <mkp@redhat.com> Signed-off-by:
-
- 30 May, 2022 6 commits
-
-
Peng He authored
Add a rcu_barrier before close_dpif_backer to ensure that all meters have been freed before id_pool_destory meter's id-pool. Signed-off-by:
Peng He <hepeng.0320@bytedance.com> Tested-by:
David Marchand <david.marchand@redhat.com> Reviewed-by:
-
Peng He authored
ovsrcu_barrier will block the current thread until all the postponed rcu job has been finished. it's like a OVS version of the Linux kernel rcu_barrier(). Signed-off-by:
-
Lin Huang authored
Currently the pmd-auto-lb-rebal-interval's value was not been checked properly. It maybe a negative, or too big value (>2 weeks between rebalances), which will be lead to a big unsigned value. So reset it to default if the value exceeds the max permitted as described in vswitchd.xml. Fixes: 5bf84282 ("Adding support for PMD auto load balancing") Signed-off-by:
Lin Huang <linhuang@ruijie.com.cn> Acked-by:
Kevin Traynor <ktraynor@redhat.com> Signed-off-by:
-
Lin Huang authored
The ALB parameters should never be negative. So it's to use unsigned smap_get versions to get it properly, and update VLOG formatting. Fixes: 5bf84282 ("Adding support for PMD auto load balancing") Signed-off-by:
-
Michael Phelan authored
Modify ci linux build script to use the latest DPDK stable release 21.11.1. Modify Documentation to use the latest DPDK stable release 21.11.1. Update NEWS file to reflect the latest DPDK stable release 21.11.1. FAQ is updated to reflect the latest DPDK for each OVS branch. Signed-off-by:
Michael Phelan <michael.phelan@intel.com> Acked-by:
-
Dumitru Ceara authored
There's no need to do that because we're not changing the hmap. Also, if DEBUG logging is disabled there's no need to iterate at all. Fixes: 5a9b53a5 ("ovsdb raft: Fix duplicated transaction execution when leader failover.") Signed-off-by:
Dumitru Ceara <dceara@redhat.com> Signed-off-by:
-
- 25 May, 2022 7 commits
-
-
Ilya Maximets authored
While becoming a follower, the leader aborts all the current 'in-flight' commands, so the higher layers can re-try corresponding transactions when the new leader is elected. However, most of these commands are already sent to followers as append requests, hence they will actually be committed by the majority of the cluster members, i.e. will be treated as committed by the new leader, unless there is an actual network problem between servers. However, the old leader will decline append replies, since it's not the leader anymore and commands are already completed with RAFT_CMD_LOST_LEADERSHIP status. New leader will replicate the commit index back to the old leader. Old leader will re-try the previously "failed" transaction, because "cluster error"s are temporary. If a transaction had some prerequisites that didn't allow double committing or there are other database constraints (like indexes) that will not allow a transaction to be committed twice, the server will reply to the client with a false-negative transaction result. If there are no prerequisites or additional database constraints, the server will execute the same transaction again, but as a follower. E.g. in the OVN case, this may result in creation of duplicated logical switches / routers / load balancers. I.e. resources with the same non-indexed name. That may cause issues later where ovn-nbctl will not be able to add ports to these switches / routers. Suggested solution is to not complete (abort) the commands, but allow them to be completed with the commit index update from a new leader. It the similar behavior to what we do in order to complete commands in a backward scenario when the follower becomes a leader. That scenario was fixed by commit 5a9b53a5 ("ovsdb raft: Fix duplicated transaction execution when leader failover."). Code paths for leader and follower inside the raft_update_commit_index were very similar, so they were refactored into one, since we also needed an ability to complete more than one command for a follower. Failure test added to exercise scenario of a leadership transfer. Fixes: 1b1d2e6d ("ovsdb: Introduce experimental support for clustered databases.") Fixes: 3c2d6274 ("raft: Transfer leadership before creating snapshots.") Reported-at: https://bugzilla.redhat.com/2046340 Acked-by:
Han Zhou <hzhou@ovn.org> Signed-off-by:
-
Dumitru Ceara authored
When compiled with clang and '-fsanitize=undefined' set, running 'ovsdb-client --timestamp monitor Open_vSwitch' in a sandbox triggers the following undefined behavior (flagged by UBSan): lib/dynamic-string.c:207:38: runtime error: applying zero offset to null pointer #0 0x4ebc18 in ds_put_strftime_msec lib/dynamic-string.c:207:38 #1 0x4ebd04 in xastrftime_msec lib/dynamic-string.c:225:5 #2 0x552e6a in table_format_timestamp__ lib/table.c:226:12 #3 0x552852 in table_print_timestamp__ lib/table.c:233:27 #4 0x5506f3 in table_print_table__ lib/table.c:254:5 #5 0x550633 in table_format lib/table.c:601:9 #6 0x5524f3 in table_print lib/table.c:633:5 #7 0x44dc5e in monitor_print_table ovsdb/ovsdb-client.c:1019:5 #8 0x44c650 in monitor_print ovsdb/ovsdb-client.c:1040:13 #9 0x44ac56 in do_monitor__ ovsdb/ovsdb-client.c:1500:21 #10 0x44636e in do_monitor ovsdb/ovsdb-client.c:1575:5 #11 0x442c41 in main ovsdb/ovsdb-client.c:283:5 Reported-by: -
Aaron Conole authored
This reverts commit c645550b ("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: c645550b ("odp-util: Always report ODP_FIT_TOO_LITTLE for IGMP.") Signed-off-by:
-
wenxu authored
During native tunnel encapsulation process, on tunnel neighbor cache miss OVS sends an arp/nd request. Currently, tunnel source is used as arp spa. Find the spa which has the same subnet with the nexthop of tunnel dst on egress port, if false, use the tunnel src as spa. For example: tunnel src is a vip with 10.0.0.7/32, tunnel dst is 10.0.1.7 the br-phy with address 192.168.0.7/24 and the default gateway is 192.168.0.1 So the spa of arp request for 192.168.0.1 should be 192.168.0.7 but not 10.0.0.7 Signed-off-by:
wenxu <wenxu@chinatelecom.cn> Acked-by:
-
wenxu authored
Rename get_src_addr to ovs_router_get_netdev_source_address and expose this function to be used in the next commit. Signed-off-by:
-
lic121 authored
Once ct_zone timeout policy changes, revalidator is supposed to be triggered. Fixes: 993cae67 ("ofproto-dpif: Consume CT_Zone, and CT_Timeout_Policy tables") Signed-off-by:
lic121 <lic121@chinatelecom.cn> Acked-by:
-
hxie authored
OvsExtSendNBLComplete always release NBLs with flag SINGL_SOURCE, this is an efficient way, which requires all the NBLs having the same source port, when cloned/fragment NBLs are released, the parent NBLs will be released as well, the problem is that a parent NBL may have a different source port from the cloned/fragment NBL, so releasing the parent NBLs with flag SINGLE_SOURCE is not corrct, see: https://github.com/microsoft/hcsshim/issues/1056 When this happens, commands 'Get-NetAdapter' and 'Get-HnsEndpoint' in the Windows node show that one net-adapter/hns-endpoint is in 'disconnected' state, meanwhile, following processes are affected, ecah of them has one thread pending on a lock: vmcompute.exe containerd.exe antrea-agent.exe To fix this issue, we may check SourcePortId in each parent NBLs before released. A simple way to reprodue this issue: 1, Enable encap mode 2, create 2 nodes, nodeA and nodeB 3, create podA with image k8s.gcr.io/e2e-test-images/agnhost:2.21 on nodeA, run 'iperf/iperf.exe -s -p 9000 -D' 4, create podB with same image on nodeB, run command 'iperf/iperf.exe -c <podA-ip> -p 9000' 5, delete podB 6, run 'Get-NetAdapter' on nodeB, you will find the leaked net adapter. Signed-off-by:Hongsheng Xie <hxie@vmware.com> Signed-off-by:
Alin-Gabriel Serdean <aserdean@ovn.org>
-
- 17 May, 2022 5 commits
-
-
Rosemarie O'Riorden authored
The FreeBSD CI builds keep failing because processes of tests are not properly killed. This leaves the build hanging until it times out, and ultimately fails. Changes name of pidfile pid2 to 2.pid so that the on_exit 'kill `cat *.pid`' will capture all pidfiles. Fixes pidfile name logic in test that uses OVSDB_SERVER_SHUTDOWN_N, so that all pidfile names match the form *.pid. Replaces unnecessary --pidfile="`pwd`"/pid with just --pidfile, because by default this argument creates a pidfile named <proc-name>.pid. Removes extra [test ! -e pid || kill `cat pid`] that run upon AT_CHECK failure, because those processes are killed with on_exit. Also adds on_exit in tests where it was missing. Fixes: 56120500 ("tests: Get rid of overly specific --pidfile and --unixctl options.") Fixes: 0be15ad7 ("ovsdb-server.at: Add unit test for record/replay.") Fixes: 7964ffe7 ("ovsdb: relay: Add support for transaction forwarding.") Fixes: e879d33e ("ovsdb/jsonrpc-server: ovsdb-server closes accepted connections immediately.") Reported-at: https://github.com/cirruslabs/cirrus-ci-docs/issues/910 Signed-off-by:
Rosemarie O'Riorden <roriorden@redhat.com> Signed-off-by:
-
Han Ding authored
When setting just one ofp version to protocols of bridge, The function get_highest_ofp_version in ovs-save parse it error. For example: $ ovs-vsctl get bridge br-int protocols [OpenFlow15] $ ovs-vsctl get bridge br-int protocols | sed 's/[][]//g' | sed 's/\ //g' | awk -F ',' '{ print (NF>1)? $(NF) : "OpenFlow14" }' OpenFlow14 Signed-off-by:Adrian Moreno <amorenoz@redhat.com> Signed-off-by:
-
Dumitru Ceara authored
Detected by UB Sanitizer when running system tests: lib/netdev-linux.c:6250:26: runtime error: member access within misaligned address 0x00000229a204 for type 'const struct rpl_rtnl_link_stats64', which requires 8 byte alignment 0x00000229a204: note: pointer points here c4 00 17 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ 00 00 00 00 6e 00 00 00 00 00 00 00 6e 00 00 00 0 0x89f10e in netdev_stats_from_rtnl_link_stats64 lib/netdev-linux.c:6250 1 0x89f10e in get_stats_via_netlink lib/netdev-linux.c:6298 2 0x8a039a in netdev_linux_get_stats lib/netdev-linux.c:2227 3 0x68e149 in netdev_get_stats lib/netdev.c:1599 4 0x407b21 in iface_refresh_stats vswitchd/bridge.c:2687 5 0x419eb6 in iface_create vswitchd/bridge.c:2134 6 0x419eb6 in bridge_add_ports__ vswitchd/bridge.c:1170 7 0x41f71c in bridge_add_ports vswitchd/bridge.c:1181 8 0x41f71c in bridge_reconfigure vswitchd/bridge.c:898 9 0x429f59 in bridge_run vswitchd/bridge.c:3331 10 0x430af3 in main vswitchd/ovs-vswitchd.c:129 11 0x7fbdfd43eb74 in __libc_start_main (/lib64/libc.so.6+0x27b74) 12 0x4072fd in _start (/root/ovs/vswitchd/ovs-vswitchd+0x4072fd) Signed-off-by: -
Dumitru Ceara authored
This is undefined behavior and was reported by UB Sanitizer: lib/meta-flow.c:3445:16: runtime error: member access within null pointer of type 'struct vl_mf_field' 0 0x6aad0f in mf_get_vl_mff lib/meta-flow.c:3445 1 0x6d96d7 in mf_from_oxm_header lib/nx-match.c:260 2 0x6d9e2e in nx_pull_header__ lib/nx-match.c:341 3 0x6daafa in nx_pull_header lib/nx-match.c:488 4 0x6abcb6 in mf_vl_mff_nx_pull_header lib/meta-flow.c:3605 5 0x73b9be in decode_NXAST_RAW_REG_MOVE lib/ofp-actions.c:2652 6 0x764ccd in ofpact_decode lib/ofp-actions.inc2:4681 [...] lib/sset.c:315:12: runtime error: applying zero offset to null pointer 0 0xcc2e6a in sset_at_position lib/sset.c:315:12 1 0x5734b3 in port_dump_next ofproto/ofproto-dpif.c:4083:20 [...] lib/ovsdb-data.c:2194:56: runtime error: applying zero offset to null pointer 0 0x5e9530 in ovsdb_datum_added_removed lib/ovsdb-data.c:2194:56 1 0x4d6258 in update_row_ref_count ovsdb/transaction.c:335:17 2 0x4c360b in for_each_txn_row ovsdb/transaction.c:1572:33 [...] lib/ofpbuf.c:440:30: runtime error: applying zero offset to null pointer 0 0x75066d in ofpbuf_push_uninit lib/ofpbuf.c:440 1 0x46ac8a in ovnacts_parse lib/actions.c:4190 2 0x46ad91 in ovnacts_parse_string lib/actions.c:4208 3 0x4106d1 in test_parse_actions tests/test-ovn.c:1324 [...] lib/ofp-actions.c:3205:22: runtime error: applying non-zero offset 2 to null pointer 0 0x6e1641 in set_field_split_str lib/ofp-actions.c:3205:22 [...] lib/tnl-ports.c:74:12: runtime error: applying zero offset to null pointer 0 0xceffe7 in tnl_port_cast lib/tnl-ports.c:74:12 1 0xcf14c3 in map_insert lib/tnl-ports.c:116:13 [...] ofproto/ofproto.c:8905:16: runtime error: applying zero offset to null pointer 0 0x556795 in eviction_group_hash_rule ofproto/ofproto.c:8905:16 1 0x503f8d in eviction_group_add_rule ofproto/ofproto.c:9022:42 [...] Also, it's valid to have an empty ofpact list and we should be able to try to iterate through it. UB Sanitizer report: include/openvswitch/ofp-actions.h:222:12: runtime error: applying zero offset to null pointer 0 0x665d69 in ofpact_end ./include/openvswitch/ofp-actions.h:222:12 1 0x66b2cf in ofpacts_put_openflow_actions lib/ofp-actions.c:8861:5 2 0x6ffdd1 in ofputil_encode_flow_mod lib/ofp-flow.c:447:9 [...] Signed-off-by: -
Dumitru Ceara authored
UB Sanitizer reports: tests/test-hash.c:59:40: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' 0 0x44c3c9 in get_range128 tests/test-hash.c:59 1 0x44cb2e in check_hash_bytes128 tests/test-hash.c:178 2 0x44d14d in test_hash_main tests/test-hash.c:282 [...] ofproto/ofproto-dpif-xlate.c:5607:45: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int' 0 0x53fe9f in xlate_sample_action ofproto/ofproto-dpif-xlate.c:5607 1 0x54d625 in do_xlate_actions ofproto/ofproto-dpif-xlate.c:7160 2 0x553b76 in xlate_actions ofproto/ofproto-dpif-xlate.c:7806 3 0x4fcb49 in upcall_xlate ofproto/ofproto-dpif-upcall.c:1237 4 0x4fe02f in process_upcall ofproto/ofproto-dpif-upcall.c:1456 5 0x4fda99 in upcall_cb ofproto/ofproto-dpif-upcall.c:1358 [...] tests/test-util.c:89:23: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' 0 0x476415 in test_ctz tests/test-util.c:89 [...] lib/dpif-netlink.c:396:33: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' 0 0x571b9f in dpif_netlink_open lib/dpif-netlink.c:396 Acked-by:Paolo Valerio <pvalerio@redhat.com> Signed-off-by:
-
- 04 May, 2022 7 commits
-
-
Mike Pattrick authored
Currently, ovs_dump_packets will break the formatting of the GDB terminal UI, resulting in artifacts displayed on the screen that may make packets difficult to read. This patch suppresses stderr output from tcpdump and feeds tcpdumps stdout into the paginated output stream. Signed-off-by:
-
lic121 authored
During the revalidation/upcall, mirror could be removed. Instead of crash the process, we can simply skip the deleted mirror. The issue had been triggered multiple times by ovs-tcpdump in my test. Fixes: ec7ceaed ("ofproto-dpif: Modularize mirror code.") Signed-off-by:
-
David Marchand authored
Dropped packets were not counted as tx_dropped when a DPDK netdev is down (like after calling netdev-dpdk/set-admin-state dpdk1 down). Fixes: 3b1fb077 ("netdev-dpdk: Don't call rte_dev_stop() in update_flags().") Signed-off-by:
Sunil Pai G <sunil.pai.g@intel.com> Signed-off-by:
-
David Marchand authored
A lock annotation was left behind after removing the nonpmd mutex. Remove it. Fixes: 1166b0d8 ("netdev-dpdk: Remove useless nonpmd_mempool_mutex.") Signed-off-by:
-
Flavio Leitner authored
This patch split out the common code between vhost and dpdk transmit paths to shared functions to simplify the code and fix an issue. The issue is that the packet coming from non-DPDK device and egressing on a DPDK device currently skips the hwol preparation. Signed-off-by:
Flavio Leitner <fbl@sysclose.org> Signed-off-by:
-
Eli Britstein authored
For VLANs, the match of ethernet type should be specified in inner_type field of the vlan match, and not type field in ethernet match. Fix it. Fixes: e8a2b5bf ("netdev-dpdk: implement flow offload with rte flow") Signed-off-by:
Eli Britstein <elibr@nvidia.com> Reviewed-by:
Salem Sol <salems@nvidia.com> Signed-off-by:
-
Eli Britstein authored
DPDK 20.11 introduced an ability to specify existance/non-existance of VLAN tag by [1]. Use this attribute. [1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items") Signed-off-by:
-
- 02 May, 2022 1 commit
-
-
Terry Wilson authored
Prior to 4e3966e64, when calling _uuid_to_row, it would raise an AttributeError when trying to access base.ref_table.rows if the referenced table was not registered. When called from Row.__getattr__(), this would appropriately raise an AttributeError. After 4e3966e64, a KeyError would be raised, which is not expected from a getattr() or hasattr() call, which could break existing code. Fixes: 4e3966e64bed ("python: Politely handle misuse of table.condition.") Signed-off-by:Terry Wilson <twilson@redhat.com> Signed-off-by:
-
- 27 Apr, 2022 2 commits
-
-
Thilak Raj Surendra Babu authored
When a packet is received over an access port that needs to be sent over a vxlan tunnel,the access port VLAN id is used in the lookup leading to a wrong packet being crafted and sent over the tunnel. Clear out the flow 's VLAN field as it should not be used while performing mac lookup for the outer tunnel and also at this point the VLAN action related to inner flow is already committed. Fixes: 7c12dfc5 ("tunneling: Avoid datapath-recirc by combining recirc actions at xlate.") Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2022-April/393566.html Reported-at: https://bugzilla.redhat.com/2060552 Signed-off-by:
Thilak Raj Surendra Babu <thilakraj.sb@nutanix.com> Signed-off-by:
-
Cian Ferriter authored
UINT64_C(1) is required in this bitshift since batch_size can be 32 and 1 << 32 overflows UINT32_C(1). Fixes: ba0a2619ca0c ("dpif-netdev-avx512: Fix ubsan shift error in bitmasks.") Signed-off-by:Harry van Haaren <harry.van.haaren@intel.com> Signed-off-by:
-
- 26 Apr, 2022 4 commits
-
-
Harry van Haaren authored
The code changes here are to handle (1 << i) shifts where 'i' is the packet index in the batch, and 1 << 31 is an overflow of the signed '1'. Fixed by adding UINT32_C() around the 1 character, ensuring compiler knows the 1 is unsigned (and 32-bits). Undefined Behaviour sanitizer is now happy with the bit-shifts at runtime. Suggested-by:
-
Terry Wilson authored
Before 46d44cf3, it was technically possible to assign a monitor condition directly to Idl.tables[table_name].condition. If done before the connection was established, it would successfully apply the condition (where cond_change() actually would fail). Although this wasn't meant to be supported, several OpenStack projects made use of this. After 46d44cf3, .condition is no longer a list, but a ConditionState. Assigning a list to it breaks the Idl. The Neutron and ovsdbapp projects have patches in-flight to use Idl.cond_change() if ConditionState exists, as it now works before connection as well, but here could be other users that also start failing when upgrading to OVS 2.17. Instead of directly adding attributes to TableSchema, this adds the IdlTable/IdlColumn objects which hold Idl-specific data and adds a 'condition' property to TableSchema that maintains the old interface. Fixes: 46d44cf3 ("python: idl: Add monitor_cond_since support.") Signed-off-by:
Timothy Redaelli <tredaelli@redhat.com> Signed-off-by:
-
Jan Scheurich authored
A packet received from a tunnel port with legacy_l3 packet-type (e.g. lisp, L3 gre, gtpu) is conceptually wrapped in a dummy Ethernet header for processing in an OF pipeline that is not packet-type-aware. Before transmission of the packet to another legacy_l3 tunnel port, the dummy Ethernet header is stripped again. In ofproto-xlate, wrapping in the dummy Ethernet header is done by simply changing the packet_type to PT_ETH. The generation of the push_eth datapath action is deferred until the packet's flow changes need to be committed, for example at output to a normal port. The deferred Ethernet encapsulation is marked in the pending_encap flag. This patch fixes a bug in the translation of the output action to a legacy_l3 tunnel port, where the packet_type of the flow is reverted from PT_ETH to PT_IPV4 or PT_IPV6 (depending on the dl_type) to remove its Ethernet header without clearing the pending_encap flag if it was set. At the subsequent commit of the flow changes, the unexpected combination of pending_encap == true with an PT_IPV4 or PT_IPV6 packet_type hit the OVS_NOT_REACHED() abortion clause. The pending_encap is now cleared in this situation. Reported-by:
Dincer Beken <dbeken@blackned.de> Signed-off-by:
Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by:
-
Paolo Valerio authored
The test relied on the flows installed by recv_upcalls() after upcall_receive() returned ENODEV if the packet was initially originated by packet-out with OFPP_CONTROLLER as in_port. Since 323ae1e8 ("ofproto-dpif-xlate: Fix recirculation when in_port is OFPP_CONTROLLER.") the test stopped working because recirculation in such scenario got fixed and upcall_receive() no longer returns ENODEV. Fix it by setting an invalid as "in_port" in order to similarly trigger the same behavior. Signed-off-by:
-
- 19 Apr, 2022 3 commits
-
-
James Page authored
-
James Page authored
-
James Page authored
-
