diff options
author | Steven Luong <sluong@cisco.com> | 2020-06-10 23:38:41 -0700 |
---|---|---|
committer | Dave Barach <openvpp@barachs.net> | 2020-06-12 19:07:01 +0000 |
commit | 1eae8ecb7acc7d80d5c08e300295bec94bf78f0b (patch) | |
tree | c40bd4cd915abbc95f13e9c31530711335727edc /build/external | |
parent | 38b09681a0e68b3711206516bc220599f6a73281 (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 'build/external')
0 files changed, 0 insertions, 0 deletions