I haven't noticed totemrrp_recv_flush will call net_deliver_fn finally.
You make me suddenly see the light, exciting patch!
On Mon, Dec 12, 2011 at 11:12 PM, Steven Dake <sdake@xxxxxxxxxx> wrote:
> Flush of regular mcast messages could trigger entry into gather state if the
> regular mcast message in the kernel buffers contained a foriegn message. This
> should set orf_token_dicard to 1. Unfortunately if this happens, the following
> ORF tokens in the kernel buffer that are flushed should be rejected. Since
> the flush occurs after the check for orf_token_discard==1, the orf token is
> not rejected.
>
> Signed-off-by: Steven Dake <sdake@xxxxxxxxxx>
> ---
> exec/totemsrp.c | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/exec/totemsrp.c b/exec/totemsrp.c
> index 5a78962..9c7b01d 100644
> --- a/exec/totemsrp.c
> +++ b/exec/totemsrp.c
> @@ -3451,9 +3451,6 @@ static int message_handler_orf_token (
> "Time since last token %0.4f ms\n", ((float)tv_diff) / 1000000.0);
> #endif
>
> - if (instance->orf_token_discard) {
> - return (0);
> - }
> #ifdef TEST_DROP_ORF_TOKEN_PERCENTAGE
> if (random()%100 < TEST_DROP_ORF_TOKEN_PERCENTAGE) {
> return (0);
> @@ -3499,6 +3496,16 @@ static int message_handler_orf_token (
> totemrrp_recv_flush (instance->totemrrp_context);
>
> /*
> + * Discard orf tokens in GATHER/COMMIT after recv_flush operation.
> + *
> + * It is possible a foreign message caused a shift to the GATHER
> + * state.
> + */
> + if (instance->orf_token_discard) {
> + return (0);
> + }
> +
> + /*
> * Determine if we should hold (in reality drop) the token
> */
> instance->my_token_held = 0;
> --
> 1.7.7.3
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
--
Yunkai Zhang
Work at Taobao
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
