[ovs-build] Failed: dceara/ovn#120 (bug-inc-processing-stale-data-v8 - 68b3e2d)

Travis CI builds at travis-ci.org
Wed Dec 4 16:41:07 UTC 2019


Build Update for dceara/ovn
-------------------------------------

Build: #120
Status: Failed

Duration: 20 mins and 15 secs
Commit: 68b3e2d (bug-inc-processing-stale-data-v8)
Author: Dumitru Ceara
Message: ovn-controller: Fix use of dangling pointers in I-P runtime_data.

The incremental processing engine might stop a run before the
en_runtime_data node is processed. In such cases the ed_runtime_data
fields might contain pointers to already deleted SB records. For
example, if a port binding corresponding to a patch port is removed from
the SB database and the incremental processing engine aborts before the
en_runtime_data node is processed then the corresponding local_datapath
hashtable entry in ed_runtime_data is stale and will store a pointer to
the already freed sbrec_port_binding record.

This will cause invalid memory accesses in various places (e.g.,
pinctrl_run() -> prepare_ipv6_ras()).

To fix the issue we introduce the engine_get_data() API which must be
called in order to safely access internal node data. If the node is in
state EN_STALE or EN_ABORTED, engine_get_data() returns NULL as the
references might be stale.

This commit also adds an "is_valid()" method to engine nodes to allow
users to override the default behavior of determining if data is valid in a
node (e.g., for the ct-zones node the data is always safe to access).

Also, all interactions with node data outside inc-proc-eng.c are now
performed through APIs and never by directly accessing the node->data
field. This makes it easier to ensure that we don't access invalid
(stale) data.

CC: Han Zhou <hzhou at ovn.org>
Fixes: ca278d98a4f5 ("ovn-controller: Initial use of incremental engine - quiet mode.")
Signed-off-by: Dumitru Ceara <dceara at redhat.com>

---
v8:
- First two patches were applied to master, so resending the last patch
  in the series as standalone patch.
- Address Han's comments:
    - Remove internal_data from engine_node.
    - Use the newly added engine_get_data() to make sure we access valid
      data outside the incremental processing engine.
    - Remove data storage outside the nodes and have the init()
      callbacks allocate and initialize required memory.
- Also, for better data encapsulations:
    - Remove all references of engine_node->data from ovn-controller.c
      and use inc-proc-eng APIs to access the data.
    - Change all init/cleanup/run/change_handlers to use data supplied
      as argument.
    - Use the newly added engine_get_input_data api to access input node
      data.
    - At init time, use engine_get_internal_data() to initialize the
      callback arguments for the unix cmd handlers and to initialize
      ofctrl.

View the changeset: https://github.com/dceara/ovn/compare/d6a448106db6^...68b3e2d2cecf

View the full build log and details: https://travis-ci.org/dceara/ovn/builds/620702770?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the dceara/ovn repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=25507942&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20191204/d79a30a8/attachment-0001.html>


More information about the build mailing list