[ovs-git] [openvswitch/ovs] 4f1506: monitor: Fix bad caching of conditional monitor_co...

GitHub noreply at github.com
Thu Aug 31 14:55:12 UTC 2017


  Branch: refs/heads/branch-2.6
  Home:   https://github.com/openvswitch/ovs
  Commit: 4f1506c25090612b651d055eced63bcd3bc87a34
      https://github.com/openvswitch/ovs/commit/4f1506c25090612b651d055eced63bcd3bc87a34
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-08-31 (Thu, 31 Aug 2017)

  Changed paths:
    M ovsdb/monitor.c

  Log Message:
  -----------
  monitor: Fix bad caching of conditional monitor_cond requests.

The current implementation of ovsdb-server caches only non-conditional
monitors, that is, monitors for every table row, not those that monitor
only rows that match some condition.  To figure out which monitors are
conditional, the code track the number of tables that have conditions that
are uniformly true (cond->n_true_cnd) and compares that against the number
of tables in the condition (shash_count(&cond->tables)).  If they are the
same, then every table has (effectively) no condition, and so
cond->conditional is set to false.

However, the implementation was buggy.  The function that adds a new
table condition, ovsdb_monitor_table_condition_create(), only updated
cond->conditional if the table condition being added was true.  This is
wrong; only adding a non-true condition can actually change
cond->conditional.  This commit fixes the problem by always recalculating
cond->conditional.

The most visible side effect of cond->conditional being true when it
should be false, as caused by this bug, was that conditional monitors were
being mixed with unconditional monitors for the purpose of caching.  This
meant that, if a client requested a conditional monitor that was the
same as an unconditional one, except for the condition, then the client
would receive the cached data previously sent for the unconditional one.
This commit fixes the problem.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Andy Zhou <azhou at ovn.org>
Acked-by: Liran Schour <lirans at il.ibm.com>




More information about the git mailing list