From: Joao Eduardo Luis <joao@suse.de>
Date: Wed, 21 Dec 2016 23:40:47 +0000 (+0000)
Subject: mon: MonMap: clear 'mon_info' during decode
X-Git-Tag: v11.1.1~3
X-Git-Url: http://git.apps.os.sepia.ceph.com/?a=commitdiff_plain;h=36ecfbd8bf022cc4ad71f5e3a15bd50814b86aeb;p=ceph.git

mon: MonMap: clear 'mon_info' during decode

It so happens that it's not safe to assume the monmap will be in an
empty state upon decoding.

Turns out the MonClient will reuse the MonMap instance when decoding
the just received map from the monitors. Should the monitors be on an
older version that do not support 'mon_info', this field will not be
decoded (after all, there's no field to decode from); but by this time,
the MonClient would already have a built monmap, which could have
populated 'mon_info' with temporary mon names from 'mon initial
members'.

Given the existing entries in 'mon_info', and the conflicting entries in
'mon_addr', we would end up asserting in 'sanitize_mons()'. This becomes
a non-issue if 'mon_info' is empty, as was unfortunately presumed.

Fixes: http://tracker.ceph.com/issues/18265
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
---

diff --git a/src/mon/MonMap.cc b/src/mon/MonMap.cc
index e5dfae60eb750..d388424c9ab78 100644
--- a/src/mon/MonMap.cc
+++ b/src/mon/MonMap.cc
@@ -209,6 +209,11 @@ void MonMap::decode(bufferlist::iterator &p)
   }
   if (struct_v >= 5) {
     ::decode(mon_info, p);
+  } else {
+    // we may be decoding to an existing monmap; if we do not
+    // clear the mon_info map now, we will likely incur in problems
+    // later on MonMap::sanitize_mons()
+    mon_info.clear();
   }
   DECODE_FINISH(p);
   sanitize_mons(mon_addr);