After the representative of the new ring entered into RECOVERY state,
it was waiting for the commit_token on the second rotation. But when
it got a new commit_token, it didn't check the status of this token
which could be retransmitted by upstream node on the first rotation,
and then the representative node would send the initial ORF token
prematurely.
If other nodes which have not entered into RECOVERY state received this
incorrect initial orf_token(which seq is 0), these nodes may crash
caused by assert instraction in *orf_token_rtr* function:
...
range = orf_token->seq - instance->my_aru;
assert (range < QUEUE_RTR_ITEMS_SIZE_MAX);
...
Signed-off-by: Yunkai Zhang <qiushu.zyk@xxxxxxxxxx>
---
exec/totemsrp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exec/totemsrp.c b/exec/totemsrp.c
index 5a78962..22717ac 100644
--- a/exec/totemsrp.c
+++ b/exec/totemsrp.c
@@ -4372,7 +4372,8 @@ static int message_handler_memb_commit_token (
break;
case MEMB_STATE_RECOVERY:
- if (totemip_equal (&instance->my_id.addr[0], &instance->my_ring_id.rep)) {
+ if (totemip_equal (&instance->my_id.addr[0], &instance->my_ring_id.rep) &&
+ memb_commit_token->token_seq == 2*memb_commit_token->addr_entries) {
log_printf (instance->totemsrp_log_level_debug,
"Sending initial ORF token\n");
--
1.7.7.3
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
