Newer
Older
Fixes: 33604c31354a ("vfio: refactor PCI BAR mapping")
Cc: stable@dpdk.org
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Tested-by: Harman Kalra <hkalra@marvell.com>
Tested-by: David Marchand <david.marchand@redhat.com>
Tested-by: Thierry Martin <thierry.martin.public@gmail.com>
(cherry picked from commit 54f3fb127d9c265a5724d193e5c7c6db29fb4150)
Resolves: #1851169
* Fri Jun 05 2020 Ilya Maximets <i.maximets@redhat.com> - 2.13.0-38
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
- raft: Avoid sending equal snapshots. [RH git: 3168eba559] (#1834838)
[ upstream commit 8c2c503bdb0da1ce6044a53d462f905fd4f8acf5 ]
Snapshots are huge. In some cases we could receive several outdated
append replies from the remote server. This could happen in high
scale cases if the remote server is overloaded and not able to process
all the raft requests in time. As an action to each outdated append
reply we're sending full database snapshot. While remote server is
already overloaded those snapshots will stuck in jsonrpc backlog for
a long time making it grow up to few GB. Since remote server wasn't
able to timely process incoming messages it will likely not able to
process snapshots leading to the same situation with low chances to
recover. Remote server will likely stuck in 'candidate' state, other
servers will grow their memory consumption due to growing jsonrpc
backlogs:
jsonrpc|INFO|excessive sending backlog, jsonrpc: ssl:192.16.0.3:6644,
num of msgs: 3795, backlog: 8838994624.
This patch is trying to avoid that situation by avoiding sending of
equal snapshot install requests. This helps maintain reasonable memory
consumption and allows the cluster to recover on a larger scale.
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Related: #1834838
Signed-off-by: Ilya Maximets <i.maximets@redhat.com>
* Fri Jun 05 2020 Ilya Maximets <i.maximets@redhat.com> - 2.13.0-37
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
- ovsdb-server: Fix schema leak while reading db. [RH git: 92a1e56c8a] (#1834838)
[ upstream commit 16e3a80cf646f6c53d22ef98599d5aecb8310414 ]
parse_txn() function doesn't always take ownership of the 'schema'
passed. So, if the schema of the clustered db has same version as the
one that already in use, parse_txn() will not use it, resulting with a
memory leak:
7,827 (56 direct, 7,771 indirect) bytes in 1 blocks are definitely lost
at 0x483BB1A: calloc (vg_replace_malloc.c:762)
by 0x44AD02: xcalloc (util.c:121)
by 0x40E70E: ovsdb_schema_create (ovsdb.c:41)
by 0x40EA6D: ovsdb_schema_from_json (ovsdb.c:217)
by 0x415EDD: ovsdb_storage_read (storage.c:280)
by 0x408968: read_db (ovsdb-server.c:607)
by 0x40733D: main_loop (ovsdb-server.c:227)
by 0x40733D: main (ovsdb-server.c:469)
While we could put ovsdb_schema_destroy() in a few places inside
'parse_txn()', from the users' point of view it seems better to have a
constant argument and just clone the 'schema' if needed. The caller
will be responsible for destroying the 'schema' it owns.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Related: #1834838
Signed-off-by: Ilya Maximets <i.maximets@redhat.com>
* Fri Jun 05 2020 Ilya Maximets <i.maximets@redhat.com> - 2.13.0-36
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
- ovsdb: Add raft memory usage to memory report. [RH git: fb32a78921] (#1834838)
[ upstream commit 3423cd97f88fe6a8de8b649d79fe6ac83bce94d1 ]
Memory reports could be found in logs or by calling 'memory/show'
appctl command. For ovsdb-server it includes information about db
cells, monitor connections with their backlog size, etc. But it
doesn't contain any information about memory consumed by raft.
Backlogs of raft connections could be insanely large because of
snapshot installation requests that simply contains the whole database.
In not that healthy clusters where one of ovsdb servers is not able to
timely handle all the incoming raft traffic, backlog on a sender's side
could cause significant memory consumption issues.
Adding new 'raft-connections' and 'raft-backlog' counters to the
memory report to better track such conditions.
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Related: #1834838
Signed-off-by: Ilya Maximets <i.maximets@redhat.com>
- netdev-offload-tc: Re-fetch block ID after probing. [RH git: d14e39f81b]
It's possible that block_id could changes after the probe for block
support. Therefore, fetch the block_id again after the probe.
Fixes: edc2055a2bf7 ("netdev-offload-tc: Flush rules on ingress block when init tc flow api")
Cc: Dmytro Linkin <dmitrolin@mellanox.com>
Acked-by: Roi Dayan <roid@mellanox.com>
Co-authored-by: Marcelo Leitner <mleitner@redhat.com>
Signed-off-by: Marcelo Leitner <mleitner@redhat.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
- netdev-linux: Update LAG in all cases. [RH git: 8b15547574]
In some cases, when processing a netlink change event, it's possible for
an alternate part of OvS (like the IPv6 endpoint processing) to hold an
active netdev interface. This creates a race-condition, where sometimes
the OvS change processing will take the normal path. This doesn't work
because the netdev device object won't actually be enslaved to the
ovs-system (for instance, a linux bond) and ingress qdisc entries will
be missing.
To address this, we update the LAG information in ALL cases where
LAG information could come in.
Fixes: d22f8927c3c9 ("netdev-linux: monitor and offload LAG slaves to TC")
Cc: Marcelo Leitner <mleitner@redhat.com>
Cc: John Hurley <john.hurley@netronome.com>
Acked-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Wed May 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-33
- vhost: fix potential fd leak [RH git: a9e6e35814]
Vhost will create temporary file when receiving VHOST_USER_GET_INFLIGHT_FD
message. Malicious guest can send endless this message to drain out the
resource of host.
When receiving VHOST_USER_GET_INFLIGHT_FD message repeatedly, closing the
file created during the last handling of this message.
Fixes: d87f1a1cb7b666550 ("vhost: support inflight info sharing")
Cc: stable@dpdk.org
This issue has been assigned CVE-2020-10726
Signed-off-by: Xuan Ding <xuan.ding@intel.com>
Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
* Wed May 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-32
- vhost: fix potential memory space leak [RH git: b39bac1377]
A malicious container which has direct access to the vhost-user socket
can keep sending VHOST_USER_GET_INFLIGHT_FD messages which may cause
leaking resources until resulting a DOS. Fix it by unmapping the
dev->inflight_info->addr before assigning new mapped addr to it.
Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
Cc: stable@dpdk.org
This issue has been assigned CVE-2020-10726
Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
* Wed May 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-31
- vhost: fix translated address not checked [RH git: 7da9061642]
Malicious guest can construct desc with invalid address and zero buffer
length. That will request vhost to check both translated address and
translated data length. This patch will add missed address check.
Fixes: 75ed51697820 ("vhost: add packed ring batch dequeue")
Fixes: ef861692c398 ("vhost: add packed ring batch enqueue")
Cc: stable@dpdk.org
This issue has been assigned CVE-2020-10725
Signed-off-by: Marvin Liu <yong.liu@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
* Wed May 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-30
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
- vhost: fix vring index check [RH git: 7c4cfd12e3]
vhost_user_check_and_alloc_queue_pair() is used to extract
a vring index from a payload. This function validates the
index and is called early on in when performing message
handling. Most message handlers depend on it correctly
validating the vring index.
Depending on the message type the vring index is in
different parts of the payload. The function contains a
switch/case for each type and copies the index. This is
stored in a uint16. This index is then validated. Depending
on the message, the source index is an unsigned int. If
integer truncation occurs (uint->uint16) the top 16 bits
of the index are never validated.
When they are used later on (e.g. in
vhost_user_set_vring_num() or vhost_user_set_vring_addr())
it can lead to out of bound indexing. The out of bound
indexed data gets written to, and hence this can cause
memory corruption.
This patch fixes this vulnerability by declaring vring
index as an unsigned int in
vhost_user_check_and_alloc_queue_pair().
Fixes: 160cbc815b41 ("vhost: remove a hack on queue allocation")
Cc: stable@dpdk.org
This issue has been assigned CVE-2020-10723
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
* Wed May 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-29
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
- vhost: check log mmap offset and size overflow [RH git: 517d8488dc]
vhost_user_set_log_base() is a message handler that is
called to handle the VHOST_USER_SET_LOG_BASE message.
Its payload contains a 64 bit size and offset. Both are
added up and used as a size when calling mmap().
There is no integer overflow check. If an integer overflow
occurs a smaller memory map would be created than
requested. Since the returned mapping is mapped as writable
and used for logging, a memory corruption could occur.
Fixes: fbc4d248b198 ("vhost: fix offset while mmaping log base address")
Cc: stable@dpdk.org
This issue has been assigned CVE-2020-10722
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
- raft: Disable RAFT jsonrpc inactivity probe. [RH git: 3d9b529afb] (#1836308)
[ upstream commit 1600e0040caded7eaa9b1f41926f9619d8e0ec8d ]
With the scale test of 640 nodes k8s cluster, raft DB nodes' jsonrpc
session got closed due to the timeout of default 5 seconds probe.
It will cause disturbance of the raft cluster. Since we already have
the heartbeat for RAFT, just disable the probe between the servers
to avoid the unnecessary jsonrpc inactivity probe.
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Zhen Wang <zhewang@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Resolves: #1836308
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
- raft: Fix leak of the incomplete command. [RH git: 5c38ccd52f] (#1836307)
[ upstream commit 168beb87ca63056e8896b09a60031565b7b60728 ]
Function raft_command_initiate() returns correctly referenced command
instance. 'n_ref' equals 1 for complete commands and 2 for incomplete
commands because one more reference is in raft->commands list.
raft_handle_execute_command_request__() leaks the reference by not
returning pointer anywhere and not unreferencing incomplete commands.
792 bytes in 11 blocks are definitely lost in loss record 258 of 262
at 0x483BB1A: calloc (vg_replace_malloc.c:762)
by 0x44BA32: xcalloc (util.c:121)
by 0x422E5F: raft_command_create_incomplete (raft.c:2038)
by 0x422E5F: raft_command_initiate (raft.c:2061)
by 0x428651: raft_handle_execute_command_request__ (raft.c:4161)
by 0x428651: raft_handle_execute_command_request (raft.c:4177)
by 0x428651: raft_handle_rpc (raft.c:4230)
by 0x428651: raft_conn_run (raft.c:1445)
by 0x428DEA: raft_run (raft.c:1803)
by 0x407392: main_loop (ovsdb-server.c:226)
by 0x407392: main (ovsdb-server.c:469)
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: William Tu <u9012063@gmail.com>
Resolves: #1836307
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
- raft: Fix the problem of stuck in candidate role forever. [RH git: 9c76350e27] (#1836305)
[ upstream commit 25a7e5547f1e107db0f032ad269f447c57401531 ]
Sometimes a server can stay in candidate role forever, even if the server
already see the new leader and handles append-requests normally. However,
because of the wrong role, it appears as disconnected from cluster and
so the clients are disconnected.
This problem happens when 2 servers become candidates in the same
term, and one of them is elected as leader in that term. It can be
reproduced by the test cases added in this patch.
The root cause is that the current implementation only changes role to
follower when a bigger term is observed (in raft_receive_term__()).
According to the RAFT paper, if another candidate becomes leader with
the same term, the candidate should change to follower.
This patch fixes it by changing the role to follower when leader
is being updated in raft_update_leader().
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
- raft: Fix next_index in install_snapshot reply handling. [RH git: cc3d026992] (#1836305)
[ upstream commit 877618fc833273d1e29e012b5e925d51cba80ff5 ]
When a leader handles install_snapshot reply, the next_index for
the follower should be log_start instead of log_end, because there
can be new entries added in leader's log after initiating the
install_snapshot procedure. Also, it should send all the accumulated
entries to follower in the following append-request message, instead
of sending 0 entries, to speed up the converge.
Without this fix, there is no functional problem, but it takes
uncessary extra rounds of append-requests responsed with "inconsistency"
by follower, although finally will be converged.
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
- raft: Avoid busy loop during leader election. [RH git: 053b78c8d6] (#1836305)
[ upstream commit 3ae90e1899c5a05148ea1870d9bb4ac3c05e3a19 ]
When a server doesn't see a leader yet, e.g. during leader re-election,
if a transaction comes from a client, it will cause 100% CPU busy loop.
With debug log enabled it is like:
2020-02-28T04:04:35.631Z|00059|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00062|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00065|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00068|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00071|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00074|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
2020-02-28T04:04:35.631Z|00077|poll_loop|DBG|wakeup due to 0-ms timeout at ../ovsdb/trigger.c:164
...
The problem is that in ovsdb_trigger_try(), all cluster errors are treated
as temporary error and retry immediately. This patch fixes it by introducing
'run_triggers_now', which tells if a retry is needed immediately. When the
cluster error is with detail 'not leader', we don't immediately retry, but
will wait for the next poll event to trigger the retry. When 'not leader'
status changes, there must be a event, i.e. raft RPC that changes the
status, so the trigger is guaranteed to be triggered, without busy loop.
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
- raft: Fix raft_is_connected() when there is no leader yet. [RH git: e732012d7b] (#1836305)
[ upstream commit adc64ab057345f7004c44bf92363b9adda862134 ]
If there is never a leader known by the current server, it's status
should be "disconnected" to the cluster. Without this patch, when
a server in cluster is restarted, before it successfully connecting
back to the cluster it will appear as connected, which is wrong.
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
- ovsdb-server: Don't disconnect clients after raft install_snapshot. [RH git: 8ff30dfee6] (#1836305)
[ upstream commit f0c8b44c5832c36989fad78927407fc14e64ce46 ]
When "schema" field is found in read_db(), there can be two cases:
1. There is a schema change in clustered DB and the "schema" is the new one.
2. There is a install_snapshot RPC happened, which caused log compaction on the
server and the next log is just the snapshot, which always constains "schema"
field, even though the schema hasn't been changed.
The current implementation doesn't handle case 2), and always assume the schema
is changed hence disconnect all clients of the server. It can cause stability
problem when there are big number of clients connected when this happens in
a large scale environment.
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
- raft-rpc: Fix message format. [RH git: 914d885061] (#1836305)
[ upstream commit 78c8011f58daec41ec97440f2e42795699322742 ]
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1836305
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
* Wed Apr 22 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-20
- redhat: pkgtool: Use the oldest sha1 [RH git: 4c657a79de]
Doing git merge from a branch to another branch the tag:C0FF3E commit is
repeated, but the correct one is the oldest one.
* Mon Apr 20 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-19
- Fix building locally on Fedora 32+ [RH git: d1c89e4d99]
* Thu Apr 16 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-18
- Set -fcommon in DPDK CFLAGS [RH git: f8a379e95e]
This is needed to build on Fedora 32+
* Thu Apr 16 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-17
- Update DPDK config files for 19.11.1 [RH git: d771330907]
* Thu Apr 16 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-16
- Merge tag 'v19.11.1' into fast-datapath-rhel-8 [RH git: 0b3abfb0e6]
dpdk-19.11.1
* Tue Apr 14 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-15
- bugtool: Fix for Python3. [RH git: 71f25b7920] (#1809241)
Currently ovs-bugtool tool doesn't start on Python 3.
This commit fixes ovs-bugtool to make it works on Python 3.
Replaced StringIO.StringIO with io.BytesIO since the script is
processing binary data.
Reported-at: https://bugzilla.redhat.com/1809241
Reported-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Co-authored-by: William Tu <u9012063@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>
(cherry picked from commit 9e6c00bca9af29031d0e160d33174b7ae99b9244)
- redhat: Skip NVR check only if building rhel-8 on rhel-7. [RH git: 2b9f32bef2]
- redhat: rh-dgit-brew: Skip NVR check in RHEL-7. [RH git: 6280d8d29f]
The RPM in RHEL-7 can't parse Supplements tag in the SPEC to get
the package NVR. The NVR is used to check if brew is already done.
error: line 241: Unknown tag: Supplements: (openvswitch2.13 and network-scripts)
error: query of specfile openvswitch2.13.spec failed, can't parse
Use --skip-nvr-check to work around the issue.
- redhat: pkgtool: Use BZ id from reported-at tag. [RH git: 3ee7ec51b6]
Some upstream commits might contain the Reported-at tag
pointing to Red Hat bugzilla. In that case, use the BZ id
in the package's changelog.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
- redhat: ovsci: Schedule the CI job while brew is building. [RH git: 1551e1e70e]
The CI will wait for the brew build to complete and this helps
to have a single place to monitor and also to record in the
CI log the brew build.
- redhat: ovsci: Use the correct job name and params. [RH git: 220f32afb2]
Jenkins needs to support different use-cases so fix the
parameters to be uniform and the job name to allow multiple
triggers (formal and non-formal releases processes).
Signed-off-by: Flavio Leitner <fbl@redhat.com>
* Mon Mar 23 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-9
- Add compatibility with RHEL7 git [RH git: 3492995783]
* Mon Mar 23 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-8
- Use the date in UTC [RH git: b53bdb16b8]
In order to avoid changing date in changelog cast the date in UTC
* Mon Mar 23 2020 Numan Siddique <nusiddiq@redhat.com> - 2.13.0-7
- ofproto-dpif-xlate: Fix recirculation when in_port is OFPP_CONTROLLER. [RH git: 4ee0f6af9e] (#1775160)
[ upstream commit c5a910dd92ecbad24f86b4c59b4ff8105b5149fd ]
Recirculation usually requires finding the pre-recirculation input port.
Packets sent by the controller, with in_port of OFPP_CONTROLLER or
OFPP_NONE, do not have a real input port data structure, only a port
number. The code in xlate_lookup_ofproto_() mishandled this case,
failing to return the ofproto data structure. This commit fixes the
problem and adds a test to guard against regression.
Reported-by: Numan Siddique <numans@ovn.org>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2020-March/368642.html
Tested-by: Numan Siddique <numans@ovn.org>
Acked-by: Numan Siddique <numans@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Resolves: #1775160
Signed-off-by: Numan Siddique <nusiddiq@redhat.com>
* Wed Mar 11 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-6
- vhost: fix packed virtqueue ready condition [RH git: 0b4e7827b8] (#1812620)
[ upstream commit c5a910dd92ecbad24f86b4c59b4ff8105b5149fd ]
Consider a virtqueue ready when, apart from the descriptor area,
both event suppression areas have been mapped.
Fixes: 2d1541e2b6b3 ("vhost: add vring address setup for packed queues")
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Reviewed-by: Tiwei Bie <tiwei.bie@intel.com>
Resolves: #1812620
* Thu Feb 27 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-5
- redhat: permit make to fail when pkgtool --gen{spec,patches} exist badly [RH git: 61807f941e]
* Tue Feb 25 2020 Timothy Redaelli <tredaelli@redhat.com> - 2.13.0-4
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
- vhost: protect log address translation in IOTLB update [RH git: 0d4370404f] (#1806599)
[ upstream commit 4f37df14c405b754b5e971c75f4f67f4bb5bfdde ]
Currently, the log address translation only happens in the vhost-user's
translate_ring_addresses(). However, the IOTLB update handler is not
checking if it was mapped to re-trigger that translation.
Since the log address mapping could fail, check it on iotlb updates.
Also, check it on vring_translate() so we do not dirty pages if the
logging address is not yet ready.
Additionally, properly protect the accesses to the iotlb structures.
Fixes: fbda9f145927 ("vhost: translate incoming log address to GPA")
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Resolves: #1806599
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>