summaryrefslogtreecommitdiffstats
path: root/src/svm
diff options
context:
space:
mode:
authorSteven Luong <sluong@cisco.com>2020-06-10 23:38:41 -0700
committerDave Barach <openvpp@barachs.net>2020-06-12 19:07:01 +0000
commit1eae8ecb7acc7d80d5c08e300295bec94bf78f0b (patch)
treec40bd4cd915abbc95f13e9c31530711335727edc /src/svm
parent38b09681a0e68b3711206516bc220599f6a73281 (diff)
vlib: node recyling and node deletion missing triggering graph node sync
When recycling a graph node vnet_register_interface, it is missing an explicit call to vlib_worker_thread_node_runtime_update(). However, there is an implicit call to vlib_worker_thread_node_runtime_update() via vnet_sw_interface_set_flags_helper() if it enables a new feature on the interface for the first time. But that implicit call is not guaranteed. For example, if an interface is created, deleted, and created, then it may skip the implicit call to vlib_worker_thread_node_runtime_update(). When that happens, the graph nodes on thread 0 are not sync'ed to the worker threads. So the worker thread's graph nodes are out of sync momentarily with the main thread's graph nodes until some other event happens which calls for a sync is needed. During this window, the worker thread's graph node is vulnerable and may experience a crash. When deleting a graph node, we never trigger a sync to the worker thread. A patch was committed 3 years ago via https://gerrit.fd.io/r/c/vpp/+/7523 to fix a show run crash. In hindsight, the approach taken by 7523 is not orthogonal. While at it, let's fix it right for both issues with a call to vlib_worker_thread_node_runtime_update() in the appropriate place and remove 7523. Type: fix Ticket: VPPSUPP-86 Fixes: gerrit 7523 / 19e9d954bd9eb4f04d48640d6540198e84ef65d7 Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: Ic9472bd2d3a212dbfeceb526506ed0400983a142
Diffstat (limited to 'src/svm')
0 files changed, 0 insertions, 0 deletions