From 5e22917729791c66ea9f5dd74b36858fa73b1b28 Mon Sep 17 00:00:00 2001 From: Andy Zhou Date: Mon, 22 Feb 2016 00:24:06 -0800 Subject: [PATCH 1/1] ovsdb: Fix one off error in tracking monitor changes dbmon's changes should be stored with the next transaction number, rather than the current transaction number. This bug causes the changes of a transaction stored in a monitor to be unnoticed by the jsonrpc connections that is responsible for flush the monitor content. However, the bug was not noticed until it was exposed by a later optimization patch: "avoid unnecessary call to ovsdb_monitor_get_update()." The lack of optimization means that the update is still generated when 'unflushed' equals to n_transactions + 1, which should have indicated the monitor has been flushed already. Signed-off-by: Andy Zhou Acked-by: Liran Schour Acked-by: Ben Pfaff --- ovsdb/monitor.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/ovsdb/monitor.c b/ovsdb/monitor.c index 5ae9cdbda..0fe2bd63b 100644 --- a/ovsdb/monitor.c +++ b/ovsdb/monitor.c @@ -1121,11 +1121,24 @@ ovsdb_monitor_commit(struct ovsdb_replica *replica, struct ovsdb_monitor_aux aux; ovsdb_monitor_init_aux(&aux, m); + /* Update ovsdb_monitor's transaction number for + * each transaction, before calling ovsdb_monitor_change_cb(). */ + m->n_transactions++; ovsdb_txn_for_each_change(txn, ovsdb_monitor_change_cb, &aux); - if (aux.efficacy == OVSDB_CHANGES_REQUIRE_EXTERNAL_UPDATE) { + switch(aux.efficacy) { + case OVSDB_CHANGES_NO_EFFECT: + /* The transaction is ignored by the monitor. + * Roll back the 'n_transactions' as if the transaction + * has never happened. */ + m->n_transactions--; + break; + case OVSDB_CHANGES_REQUIRE_INTERNAL_UPDATE: + /* Nothing. */ + break; + case OVSDB_CHANGES_REQUIRE_EXTERNAL_UPDATE: ovsdb_monitor_json_cache_flush(m); - m->n_transactions++; + break; } return NULL; -- 2.20.1