[sheepdog] [PATCH 1/2] corosync: fix bug when processing blocked event

MORITA Kazutaka morita.kazutaka at lab.ntt.co.jp
Tue Jul 10 19:56:14 CEST 2012


At Wed, 11 Jul 2012 01:30:59 +0800,
Yunkai Zhang wrote:
> 
> From: Yunkai Zhang <qiushu.zyk at taobao.com>
> 
> In old code, corosync driver could not process blocked event
> correctly.
> 
> For example:
> Suppose there was two requests: R1, R2.
> 1) In queue_cluster_request(), R1 sent a BLOCK event(B1) to cluster,
>    R1 was added to sys->pending_list.
> 2) When B1 was received, cdrv_cpg_deliver() was executed, and sd_block_handler()
>    would be called in __dispatch_corosycn_one(). sd_block_handler() will get R1
>    from sys->pending_list(but not delete R1 from it), cluster_op_running was set
>    TRUE, and then queue_work().
> 3) Before cluster_op_done() of R1 was executed, R2 was coming and sent a BLOCK
>    event(B2) to cluster in queue_cluster_request().
> 4) Now, cluster_op_done() of R1 was called, R1 sent an UNBLOCK event(U1) to
>    cluster, and cluster_op_running was set FALSE.
> 5) And then, B2 was received, cdrv_cpg_deliver()->__dispatch_corosycn_one()
>    would be called. Because cluster_op_running was FALSE again, so
>    sd_block_handler() would be executed again, as R1 was also at the head of
>    sys->pending_list, then R1 would be queue_work() again, ..., this bug will
>    lead to so many segment fault.
> 
> Accord has the same problem, I will fix it in next patch. But zookeeper dirver
> works well at this situation.
> 
> Signed-off-by: Yunkai Zhang <qiushu.zyk at taobao.com>
> ---
>  sheep/cluster/corosync.c |   14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/sheep/cluster/corosync.c b/sheep/cluster/corosync.c
> index bd955bb..7810a2e 100644
> --- a/sheep/cluster/corosync.c
> +++ b/sheep/cluster/corosync.c
> @@ -38,6 +38,7 @@ static struct cpg_node cpg_nodes[SD_MAX_NODES];
>  static size_t nr_cpg_nodes;
>  static int self_elect;
>  static int join_finished;
> +static int corosync_notify_blocked;
>  
>  /* event types which are dispatched in corosync_dispatch() */
>  enum corosync_event_type {
> @@ -342,7 +343,8 @@ static int __corosync_dispatch_one(struct corosync_event *cevent)
>  		sd_leave_handler(&cevent->sender.ent, entries, nr_cpg_nodes);
>  		break;
>  	case COROSYNC_EVENT_TYPE_BLOCK:
> -		sd_block_handler(&cevent->sender.ent);
> +		if (sd_block_handler(&cevent->sender.ent))
> +			corosync_notify_blocked = 1;
>  
>  		/* block other messages until the unblock message comes */
>  		return 0;
> @@ -368,6 +370,14 @@ static void __corosync_dispatch(void)
>  			cevent = list_first_entry(&corosync_notify_list,
>  						  typeof(*cevent), list);
>  
> +		/*
> +		 * When there is unfinished blocked event, only cfgchg events
> +		 * could continue to be processed(as we have given priotiry to
> +		 * process cfgchg events now).
> +		 */
> +		if (!event_is_confchg(cevent->type) && corosync_notify_blocked)
> +			return;
> +
>  		/* update join status */
>  		if (!join_finished) {
>  			switch (cevent->type) {
> @@ -687,6 +697,8 @@ static void corosync_unblock(void *msg, size_t msg_len)
>  {
>  	send_message(COROSYNC_MSG_TYPE_UNBLOCK, 0, &this_node, NULL, 0,
>  		     msg, msg_len);
> +
> +	corosync_notify_blocked = 0;

Setting corosync_notify_blocked zero here looks wrong.  Because if
__corosync_dispatch is called before the COROSYNC_MSG_TYPE_UNBLOCK
message is arrived, sd_block_handler will be called again.  My patch
looks simpler and correct, doesn't it?

Thanks,

Kazutaka



More information about the sheepdog mailing list