Steve, rohara, using SORT_QUEUE_ITEM_MAXIOVS is really unnecessary, but it make code more readable (why somewhere should be MAGIC_CONSTANT + 1?). Anyway, there is problem and as I wrote, it's in orf_token_mcast, because you are using item 0 to save message_item->mcast and without any problem copy copy (in this case) iovec array with 5 items to &sort_queue_item.iovec[1].
So solution could be (of course) backport corosync code, because it has no such code. My solution is shorter and with 2 hours of running heavily loaded aisexec (cpgbench, evsbench, ...) didn't show any problem (of course, this doesn't mean, there couldn't be any). So for me, it looks like solve problem. Anyway, what do you think is proper solution? Honza Steven Dake wrote: > On Tue, 2009-10-27 at 18:42 -0500, Ryan O'Hara wrote: >> On Tue, Oct 27, 2009 at 06:18:44PM +0100, Jan Friesse wrote: >>> See patch. I hope this will fix >>> https://bugzilla.redhat.com/show_bug.cgi?id=525280. >>> >>> Regards, >>> Honza >>> >> Do we really need SORT_QUEUE_ITEM_MAXIOVS? Perhaps using "MAXIOVS + 1" >> in the EVT code is sufficient. >> > > My general response to this is that if we are running into the MAXIOVS > constraint on the data structure, increasing MAXIOVS by 1 is not going > to solve the problem (although it may hide this fault condition). > > The use of an extra define as you point out is unnecessary. > > Regards > -steve > >> Ryan >> >> >>> diff --git a/branches/whitetank/exec/totemsrp.c >>> b/branches/whitetank/exec/totemsrp.c >>> index c11a552..c5a74e8 100644 >>> --- a/branches/whitetank/exec/totemsrp.c >>> +++ b/branches/whitetank/exec/totemsrp.c >>> @@ -87,6 +87,7 @@ >>> #define RETRANS_MESSAGE_QUEUE_SIZE_MAX 500 /* allow 500 >>> messages to be queued */ >>> #define RECEIVED_MESSAGE_QUEUE_SIZE_MAX 500 /* allow 500 >>> messages to be queued */ >>> #define MAXIOVS 5 >>> +#define SORT_QUEUE_ITEM_MAXIOVS MAXIOVS + 1 >>> #define RETRANSMIT_ENTRIES_MAX 30 >>> #define TOKEN_SIZE_MAX 64000 /* bytes */ >>> >>> @@ -278,7 +279,7 @@ struct message_item { >>> }; >>> >>> struct sort_queue_item { >>> - struct iovec iovec[MAXIOVS]; >>> + struct iovec iovec[SORT_QUEUE_ITEM_MAXIOVS]; >>> int iov_len; >>> }; >>> >>> @@ -1916,7 +1917,7 @@ static void memb_state_recovery_enter ( >>> strcat (is_originated, seqno_string_hex); >>> sort_queue_item = ptr; >>> assert (sort_queue_item->iov_len > 0); >>> - assert (sort_queue_item->iov_len <= MAXIOVS); >>> + assert (sort_queue_item->iov_len <= SORT_QUEUE_ITEM_MAXIOVS); >>> messages_originated++; >>> memset (&message_item, 0, sizeof (struct message_item)); >>> // TODO LEAK >>> _______________________________________________ >>> Openais mailing list >>> [email protected] >>> https://lists.linux-foundation.org/mailman/listinfo/openais >> _______________________________________________ >> Openais mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/openais > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
